|
From: | Paul Eggert |
Subject: | bug#55477: 29.0.50; flymake-goto-next-eror shows terminal like color codes in mini buffer |
Date: | Wed, 18 May 2022 13:11:46 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 |
On 5/18/22 04:24, Lars Ingebrigtsen wrote:
The above expression is returning "curve"; in all three environments, en_US.UTF-8 en_IN.UTF-8 en_INThat seems like a bug, because in the final environment, Emacs doesn't seem to be able to display the curved quote.
But Emacs *can* display curved quotes in that environment. It's misdisplaying them as individual bytes, and that's the bug: it should simply display the characters as-is.
This bug is not limited to quotes. Put this into a file t.el: (defun δ-replace-string (from-string to-string) (declare (interactive-only "use `search-forward' and `replace-match' instead.")) (interactive)) (defun test-fun (obj) (if (stringp obj) (δ-replace-string "from" "to")))run "LC_ALL=en_IN emacs -Q", visit the file, evaluate the first form, and then do M-x flymake-mode followed by repeated uses of M-x flymake-goto-next-error. It will eventually report the diagnostic:
‘δ-replace-string’ is for interactive use only; use ‘search-forward’ and ‘replace-match’ instead.
That is, the "δ" (which in UTF-8 is #xCE #xB4) is misinterpreted as the two Latin-1 characters Î (#xCE) and ´ (#xB4).
I suspect that the problem is due to Alan's recent change to the meaning of EQ. As I understand it, when byte-compiling, EQ doesn't mean the same thing that it does ordinarily. But format-message (which is used by the byte compiler) uses EQ to decide what to do, and it bases its decision on whether the resulting string is unibyte or multibyte. Evidently this new meaning of EQ is messing up format-message's internals.
I'll CC this to Alan to see whether he can provide some insight.
[Prev in Thread] | Current Thread | [Next in Thread] |