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

Previous Next

Full log

View this message in rfc822 format

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: bug#79279: 28.2; Combining characters cause formatting problems when showing CAP candidates
Date: Thu, 21 Aug 2025 21:19:12 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Dmitry Safronov <saf.dmitry <at> gmail.com>,  Stefan Monnier
>  <monnier <at> iro.umontreal.ca>,  79279 <at> debbugs.gnu.org
> Date: Thu, 21 Aug 2025 19:04:17 +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?

Previous Next

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