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

Previous Next

Full log

Message #50 received at 55477 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: acm <at> muc.de, larsi <at> gnus.org, 55477 <at> debbugs.gnu.org, pankaj <at> codeisgreat.org
Subject: Re: bug#55477: 29.0.50;
 flymake-goto-next-eror shows terminal like color codes in mini buffer
Date: Thu, 19 May 2022 11:06:08 +0300

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.