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

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

[Pankaj Jangid]

I have an elisp buffer with some flymake errors. When I call
"flymake-goto-next-error" the point moves to the error location and
displays the error in minibuffer like this,

--8<---------------cut here---------------start------------->8---
‘replace-string’ is for interactive use only; use ‘search-forward’ and ‘replace-match’ instead.
user-error: Minibuffer window is not active
--8<---------------cut here---------------end--------------->8---

I think this is printing the string properties also from the buffer.

Tried it with "emacs -Q" also. Same issue.


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2022-05-17 built on anant
Repository revision: e52159d0dc45bf0a7f363c8a4cf2a490094e970b
Repository branch: master
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --prefix=/home/pankaj/.local --with-pgtk'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM
GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: en_IN.UTF-8
  value of $LC_NUMERIC: en_IN.UTF-8
  value of $LC_TIME: en_IN.UTF-8
  value of $LANG: en_IN
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: iso-latin-1-unix

Major mode: Lisp Interaction

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  company-mode: t
  flymake-mode: t
  display-line-numbers-mode: t
  electric-pair-mode: t
  editorconfig-mode: t
  which-key-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  shell-dirtrack-mode: t
  override-global-mode: t
  savehist-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/pankaj/.emacs.d/elpa/transient-20220514.945/transient hides /home/pankaj/.local/share/emacs/29.0.50/lisp/transient

Features:
(shadow flyspell ispell emacsbug misearch multi-isearch s ediff
ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init
ediff-util let-alist ido shortdoc flow-fill erc-list erc-menu erc-join
erc-ring erc-networks erc-pcomplete erc-track erc-match erc-button
erc-fill erc-stamp erc-netsplit erc-goodies erc erc-backend erc-loaddefs
newst-plainview newst-ticker cl-print debug backtrace url-http url-gw
url-auth newst-treeview tree-widget newst-reader newst-backend gnus-html
help-fns url-cache shr-color sort smiley gnus-cite qp mm-archive
mail-extr textsec uni-scripts idna-mapping ucs-normalize uni-confusable
textsec-check gnus-bcklg gnus-async gnus-ml nndraft nnmh utf-7 nnml
nnfolder bbdb-gnus bbdb-mua bbdb-com epa-file network-stream nsm
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg nntp
gnus-cache .gnus autoload radix-tree gnus-dired diary-lib diary-loaddefs
rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri
rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap sgml-mode facemenu nxml-util nxml-enc
xmltok sql view yaml-mode linum prettier-js js markdown-mode conf-mode
bug-reference ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe ol-irc
ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime
gnutls dig gnus-sum shr pixel-fill kinsoku url-file url-dired svg dom
gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap
nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range
gnus-win gnus nnheader range ol-docview doc-view image-mode exif
ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi mule-util jka-compr vc-git
checkdoc company-oddmuse company-keywords company-etags etags fileloop
company-gtags company-dabbrev-code company-dabbrev company-files
company-clang company-capf company-cmake company-semantic
company-template company-bbdb company flymake-proc flymake
display-line-numbers elec-pair editorconfig-core
editorconfig-core-handle editorconfig-fnmatch init my-init org-element
avl-tree generator org org-macro org-footnote org-pcomplete org-list
org-faces org-entities noutline outline org-version ob-plantuml ob-sql
ob-css ob-js ob-java ob-C cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs ob-python python ob-R ob
ob-tangle org-src ob-ref ob-lob ob-table ob-exp ob-comint ob-emacs-lisp
ob-core ob-eval org-table oc-basic bibtex ol org-keys oc org-compat
advice org-macs org-loaddefs cal-menu calendar cal-loaddefs warnings
sesman vc vc-dispatcher clojure-mode lisp-mnt align thingatpt
editorconfig tree-sitter-langs tree-sitter-langs-build tar-mode arc-mode
archive-mode tree-sitter-hl tree-sitter tree-sitter-load tree-sitter-cli
tsc tsc-dyn tsc-dyn-get dired-aux tsc-obsolete gtags-mode xref project
which-key vterm magit-bookmark bookmark tramp tramp-loaddefs trampver
tramp-integration cus-edit pp wid-edit files-x tramp-compat parse-time
iso8601 ls-lisp face-remap compile color term disp-table ehelp find-func
vterm-module term/xterm xterm magit-submodule magit-obsolete magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode diff
diff-mode git-commit rx log-edit pcvs-util add-log magit-core
magit-autorevert autorevert filenotify magit-margin magit-transient
magit-process with-editor shell pcomplete comint ring server ansi-color
magit-mode transient magit-git magit-base magit-section format-spec crm
dash compat-27 compat-26 compat exec-path-from-shell bbdb-message
message sendmail yank-media rmc puny dired dired-loaddefs rfc822 mml
mml-sec epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev
mail-utils gmm-utils mailheader bbdb bbdb-site timezone edmacro kmacro
modus-vivendi-theme modus-themes pcase delight cl-extra help-mode
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core hl-line
savehist desktop frameset avoid cus-load finder-inf tex-site info
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars seq gv subr-x byte-opt bytecomp
byte-compile cconv cl-loaddefs cl-lib early-init iso-transl tooltip
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice simple cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 2671984 250451)
 (symbols 48 59194 16)
 (strings 32 392630 43881)
 (string-bytes 1 15225822)
 (vectors 16 158134)
 (vector-slots 8 2743021 206641)
 (floats 8 754 607)
 (intervals 56 190877 1467)
 (buffers 992 132))

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

[Pankaj Jangid]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> I have an elisp buffer with some flymake errors. When I call
> "flymake-goto-next-error" the point moves to the error location and
> displays the error in minibuffer like this,
>
> ‘replace-string’ is for interactive use only; use ‘search-forward’ and ‘replace-match’ instead.
> user-error: Minibuffer window is not active
>
I should have sent screenshot in the first place. It appears like this (screenshot),


[-- Attachment #2: Screenshot from 2022-05-17 21-54-48.png --]
[-- Type: image/png, Size: 24943 bytes --]

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

[Lars Ingebrigtsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> Tried it with "emacs -Q" also. Same issue.

Do you have a recipe to reproduce this problem, starting from "emacs -Q"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Pankaj Jangid]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>
>> Tried it with "emacs -Q" also. Same issue.
>
> Do you have a recipe to reproduce this problem, starting from "emacs -Q"?

1. Launch Emacs with "emacs -Q". This opens *scratch* buffer already.

2. M-x flymake-mode

3. Insert the following snippet (with error)
   #+begin_src elisp
   (defun test-fun (obj)
     (if (stringp obj)
       (replace-string "from" "to")))
   #+end_src

4. Now M-x flymake-goto-next-error repeatedly until you reach the string
   "replace-string"

Result:

It shows following text in mini-buffer,

[-- Attachment #2: Screenshot from 2022-05-17 22-22-10.png --]
[-- Type: image/png, Size: 22082 bytes --]

[-- Attachment #3: Type: text/plain, Size: 145 bytes --]


As collected in the original report - I am using PGTK build on Debian
Stable. I am using just two configure options - --prefix and
--with-pgtk.

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

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 186 bytes --]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> 4. Now M-x flymake-goto-next-error repeatedly until you reach the string
>    "replace-string"

I'm unable to reproduce this.  I get:



[-- Attachment #2: Type: image/png, Size: 27759 bytes --]

[-- Attachment #3: Type: text/plain, Size: 281 bytes --]


This is not with pgtk, but that seems unlikely to make much difference
here, I'd have thought.  You're not running in a language environment
that precludes utf-8 or something?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Pankaj Jangid]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This is not with pgtk, but that seems unlikely to make much difference
> here, I'd have thought.  You're not running in a language environment
> that precludes utf-8 or something?

I am using 

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

[Pankaj Jangid]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This is not with pgtk, but that seems unlikely to make much difference
> here, I'd have thought.  You're not running in a language environment
> that precludes utf-8 or something?

Got the issue.

My desktop system language environment is en_IN (English (India)). And
those codes are coming because of this.

When I changed the language environment to en_US.UTF-8, Emacs is working
fine.

[PS: sorry about the half cooked last email. Pressed C-c C-s by mistake]

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

[Lars Ingebrigtsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

> My desktop system language environment is en_IN (English (India)). And
> those codes are coming because of this.
>
> When I changed the language environment to en_US.UTF-8, Emacs is working
> fine.

It's supposed to work automatically, though.  What's the value of your
text-quoting-style variable?  The default, nil, is supposed to result in
using "plain" quotes when it can't display the curved ones.

(text-quoting-style)
=> curve

here, but it should have returned nil in the en_IN environment you were
in, apparently.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Pankaj Jangid]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It's supposed to work automatically, though.  What's the value of your
> text-quoting-style variable?  The default, nil, is supposed to result in
> using "plain" quotes when it can't display the curved ones.
>
> (text-quoting-style)
> => curve
>
> here, but it should have returned nil in the en_IN environment you were
> in, apparently.

The above expression is returning "curve"; in all three environments,

en_US.UTF-8
en_IN.UTF-8
en_IN

I did one more experiment. I tried with LANG=en_IN.UTF-8 and it was
working fine. The bug is reproducible only with LANG=en_IN.

And I guess the desktop environment sets LANG to just en_IN or en_US
when only one variant of English is enabled in the system locales. After
adding both in locales, switch language changes it to either en_US.UTF-8
or en_IN.UTF-8.

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

[Eli Zaretskii]

> Cc: 55477@debbugs.gnu.org
> From: Pankaj Jangid <pankaj@codeisgreat.org>
> Date: Wed, 18 May 2022 09:02:14 +0530
> 
> > (text-quoting-style)
> > => curve
> >
> > here, but it should have returned nil in the en_IN environment you were
> > in, apparently.
> 
> The above expression is returning "curve"; in all three environments,
> 
> en_US.UTF-8
> en_IN.UTF-8
> en_IN

What is the value of

  (default-value 'buffer-file-coding-system)

in each of the 3 environments?

And also what does the below return in each of the 3 environments?

  (char-displayable-p ?‘)

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

[Lars Ingebrigtsen]

Pankaj Jangid <pankaj@codeisgreat.org> writes:

>> (text-quoting-style)
>> => curve
>>
>> here, but it should have returned nil in the en_IN environment you were
>> in, apparently.
>
> 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.

Looking at default_to_grave_quoting_style, I don't quite see why -- I've
added Paul to the CCs, since he wrote that function.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Paul Eggert]

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.

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

[Pankaj Jangid]

Eli Zaretskii <eliz@gnu.org> writes:

>> en_US.UTF-8
>> en_IN.UTF-8
>> en_IN
>
> What is the value of
>
>   (default-value 'buffer-file-coding-system)
>
> in each of the 3 environments?

utf-8-unix
utf-8-unix
iso-latin-1-unix

respectively

> And also what does the below return in each of the 3 environments?
>
>   (char-displayable-p ?‘)
#<font-object "-PfEd-DejaVu Sans Mono-regular-normal-normal-*-19-*-*-*-m-0-iso10646-1">
#<font-object "-PfEd-DejaVu Sans Mono-regular-normal-normal-*-19-*-*-*-m-0-iso10646-1">
#<font-object "-PfEd-DejaVu Sans Mono-regular-normal-normal-*-19-*-*-*-m-0-iso10646-1">

respectively

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

[Paul Eggert]

On 5/18/22 13:11, Paul Eggert wrote:
> I'll CC this to Alan to see  whether he can provide some insight.

After looking into this some more I'm no longer convinced that the EQ 
redefinition is the culprit, in that I disabled the fancy EQ stuff and 
the problem still occurs. Sorry about the false alarm. (Still don't know 
what the culprit is, though.)

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

Do you understand the significance of en_IN locale in this scenario?
If so, can you point out what aspect of that locale seems to cause
this issue?

Or is the same possible with other locales as well?  If so, what is
common to the problematic locales?

Thanks.

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.

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

[Pankaj Jangid]

Eli Zaretskii <eliz@gnu.org> writes:

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

The bug is fixed now. Thanks a lot.

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

[Eli Zaretskii]

> From: Pankaj Jangid <pankaj@codeisgreat.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  larsi@gnus.org,  acm@muc.de,
>   55477@debbugs.gnu.org
> Date: Thu, 19 May 2022 23:39:14 +0530
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> The bug is fixed now. Thanks a lot.

Great, thanks for testing.  Closing.