bug#40702: 28.0.50; (what-cursor-position) barfs on non-ASCII char

[Štěpán Němec]

On Sun, 19 Apr 2020 18:22:30 +0300
Eli Zaretskii wrote:

>> Looking at `what-cursor-position', apparently due to your
>> `buffer-file-coding-system' being nil (which seems a bit strange to me:
>> is even your (default-value 'buffer-file-coding-system) nil?)
>
> buffer-file-coding-system being nil means 'no-conversion'.  You can
> easily simulate that yourself, by an explicit setq, and you will then
> get the error described in the report.

Indeed, thanks, the meaning of `nil' is described in the doc string. I
was more surprised that it ever ends up being nil by default, but that's
probably because I have very little understanding of how the Emacs
coding setup works.

>> the multibyte string isn't properly encoded and instead passed
>> directly to `encoded-string-description', leading to the error.
>
> Emacs 26.3 doesn't signal an error in this case, so I think this is a
> regression we should fix.
>
>> That said, there haven't been any relevant recent changes to
>> `what-cursor-position'.
>> 
>> In any case, I think more info is needed: backtrace, system/environment.
>
> Here's a backtrace:
>
>   Debugger entered--Lisp error: (cl-assertion-failed ((not 
> (multibyte-string-p str)) nil))
>     cl--assertion-failed((not (multibyte-string-p str)))
>     encoded-string-description(#("é" 0 1 (charset unicode)) nil)
>     describe-char(146)
>     what-cursor-position((4))
>     funcall-interactively(what-cursor-position (4))
>     call-interactively(what-cursor-position nil nil)
>     command-execute(what-cursor-position)

Thanks. I was looking at all the wrong places. The problem was simply
introduced by the addition of the assert in

2019-05-28T20:59:35-04:00!monnier@iro.umontreal.ca
146486f8a6 (* mule-cmds.el (encoded-string-description): Require unibyte string 
as input)
https://git.sv.gnu.org/cgit/emacs.git/commit/?id=146486f8a6

Removing the assertion reverts to the Emacs 26 behaviour.

Unfortunately there is no explanation regarding the change. Maybe Stefan
could provide some insight?

-- 
Štěpán