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: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
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: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.

Previous Next

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