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

[Stefan Monnier]

>> I can't reproduce this on current master
> Thanks for checking. It's very consistent on my end. I poked at it a
> little bit just now.
> I see that buffer-file-coding-system is nil

It would be worth looking into how/why you get a nil value here.

> It ends up evaluating
>   (encoded-string-description "é" nil)

This seems to point to a bug in `encode-coding-char`:

    M-: (encode-coding-char ?\é nil) RET

returns "é" which is not a unibyte string and hence is not a valid
encoded string.  Note that

    M-: (encode-coding-char ?\é 'no-conversion) RET

does not suffer from the same problem.  This comes from
`encode-coding-string` which also returns a multibyte string when its
coding arg is nil.

I'm not sure if `encode-coding-string/char` should accept a nil argument
nor how it should treat it, so maybe it's a bug in `what-char-position`
which should not pass a nil argument here.  So maybe the patch below
is a good fix?


        Stefan


diff --git a/lisp/simple.el b/lisp/simple.el
index 8bc84a9dfa..e5180119e8 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1470,7 +1470,11 @@ what-cursor-position
            encoded encoding-msg display-prop under-display)
        (if (or (not coding)
                (eq (coding-system-type coding) t))
-           (setq coding (default-value 'buffer-file-coding-system)))
+           (setq coding (or (default-value 'buffer-file-coding-system)
+                             ;; A nil value of `buffer-file-coding-system'
+                             ;; means "no conversion" which means each byte
+                             ;; is a char and vice versa.
+                             'binary)))
        (if (eq (char-charset char) 'eight-bit)
            (setq encoding-msg
                  (format "(%d, #o%o, #x%x%s, raw-byte)" char char char 
char-name-fmt))