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 #11 received at 79279 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Safronov <saf.dmitry <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> linkov.net>
Cc: 79279 <at> debbugs.gnu.org
Subject: Re: bug#79279: 28.2; Combining characters cause formatting problems
 when showing CAP candidates
Date: Thu, 21 Aug 2025 17:00:52 +0300
[Please use Reply All to reply, to keep the bug tracker on the CC list.]

> From: Dmitry Safronov <saf.dmitry <at> gmail.com>
> Date: Thu, 21 Aug 2025 13:25:58 +0200
> 
> > Presenting text which starts with a combining character indeed needs
> some special code, but that code should be in the Lisp program which
> creates the text.  And given what you tell, I don't yet have an idea
> where that Lisp program is: in Emacs core, in Julia, somewhere else?
> 
> 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`).
> 
> Therefore, I think, a proper handling of annotation text which starts with a
> combining character should nevertheless be addressed in Emacs core (for example,
> by prepending annotations starting with a combining character by a
> zero-width space
> U+200B).

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