bug#55477: 29.0.50; flymake-goto-next-eror shows terminal like color codes in mini buffer

[Paul Eggert <eggert@cs.ucla.edu>]

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_IN
> That 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.