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


View this message in rfc822 format

From: Dmitry Safronov <saf.dmitry <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 79279 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca
Subject: bug#79279: 28.2; Combining characters cause formatting problems when showing CAP candidates
Date: Thu, 21 Aug 2025 22:43:26 +0200
I experimented a bit using different fonts and came to the conclusion that the
formatting issue appears only if a font does not support proper
rendering of combined
characters. Ironically, the JuliaMono font does support it and it
causes the formatting problem
described in the original post.

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

So well, nevermind, I will open an issue at
<https://github.com/JuliaEditorSupport/julia-emacs>.

On Thu, 21 Aug 2025 at 20:25, Juri Linkov <juri <at> linkov.net> wrote:
>
> >> >> 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.




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.