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

[Eli Zaretskii]

> Cc: Alan Mackenzie <acm@muc.de>, 55477@debbugs.gnu.org,
>  Pankaj Jangid <pankaj@codeisgreat.org>
> Date: Wed, 18 May 2022 13:11:46 -0700
> From: 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).

Thanks for the test case.

This has nothing to do with quoting style, nor with Alan's "symbols
with positions" changes.  The problem was that Flymake doesn't by
itself know which encoding to use for the files it checks and for
communicating with backend processes; when that is specific to the
major-mode (as in the case of ELisp, where we use UTF-8 by default),
the backend should arrange for that.

I hope I fixed that now on the master branch.