Subject: bug#79279: 28.2; Combining characters cause formatting problems when showing CAP candidates

From: Eli Zaretskii <[email-masked]>
Date: Fri, 22 Aug 2025 09:23:39 +0300

> From: Juri Linkov <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> 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.