[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40702: 28.0.50; (what-cursor-position) barfs on non-ASCII char
From: |
Eli Zaretskii |
Subject: |
bug#40702: 28.0.50; (what-cursor-position) barfs on non-ASCII char |
Date: |
Sun, 19 Apr 2020 18:22:30 +0300 |
> From: Štěpán Němec
> <stepnem@gmail.com>
> Date: Sun, 19 Apr 2020 15:02:24 +0200
> Cc: 40702@debbugs.gnu.org
>
> 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.
> 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)
- bug#40702: 28.0.50; (what-cursor-position) barfs on non-ASCII char, Dima Kogan, 2020/04/18
- bug#40702: 28.0.50; (what-cursor-position) barfs on non-ASCII char, Stefan Monnier, 2020/04/19
- bug#40702: 28.0.50; (what-cursor-position) barfs on non-ASCII char, Dima Kogan, 2020/04/20
- bug#40702: 28.0.50; (what-cursor-position) barfs on non-ASCII char, Stefan Monnier, 2020/04/20
- bug#40702: 28.0.50; (what-cursor-position) barfs on non-ASCII char, Dima Kogan, 2020/04/20