GNU bug report logs - #79279
28.2; Combining characters cause formatting problems when showing CAP candidates

Previous Next

Package: emacs;

Reported by: Dmitry Safronov <saf.dmitry <at> gmail.com>

Date: Wed, 20 Aug 2025 15:45:02 UTC

Severity: normal

Found in version 28.2

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 79279 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, saf.dmitry <at> gmail.com
Subject: Re: bug#79279: 28.2; Combining characters cause formatting problems
 when showing CAP candidates
Date: Fri, 22 Aug 2025 09:23:39 +0300
> From: Juri Linkov <juri <at> linkov.net>
> Cc: saf.dmitry <at> gmail.com,  monnier <at> iro.umontreal.ca,  79279 <at> debbugs.gnu.org
> Date: Thu, 21 Aug 2025 21:24:51 +0300
> 
> >> >> The text was indeed produced by the julia-mode package, namely by the
> >> >> `julia--latexsub-capf-list` function for creating a CAPF completion
> >> >> table for that mode.
> >> >> However, the list of completion candidates (based on that completion
> >> >> table) in the
> >> >> "*Completions*" buffer was produced by the Emacs core (`display-completion-list`
> >> >> function defined in `minibuffer.el`).
> >> >
> >> > But display-completion-list just shows the strings it gets as its
> >> > argument.  AFAIU, theses strings already include both the completion
> >> > candidate and its visualization (which causes the problem).  If that
> >> > is correct, then the code which generates those strings is the one we
> >> > need to fix.  Can you (or someone else of the people I CC) point to
> >> > the code which generates those strings?
> >> 
> >> This was already fixed in julia-mode long ago.
> >> The current version adds the preceding space character:
> >> 
> >>   :annotation-function (lambda (s)
> >>                          (concat " " (gethash s julia-mode-latexsubs)))
> >> 
> >> So there is no such problem anymore:
> >
> > So you think we don't need to solve this in minibuffer.el for all the
> > users of this?
> 
> I think it's responsibility of the caller to add a space
> when it's known that the completion candidate might contain
> a combining character.

The alternative is for us to always add a special character there,
like ZWNJ or maybe invisible TAB, like we do in other places where we
want to prevent character composition.  But if you think this is
unnecessary, I'm okay with leaving that to the calling Lisp program.




This bug report was last modified 14 days ago.

Previous Next


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