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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 23 Aug 2025 15:59:30 +0300

> From: Stefan Monnier <[email-masked]>
> Cc: Juri Linkov <[email-masked]>,  [email-masked],
>   [email-masked]
> Date: Fri, 22 Aug 2025 03:38:02 -0400
> 
> >> 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.
> > That would be The Right Thing to do, I think.
> 
> [ Sorry, sent it a bit precipitously. ]
> 
> In practice it's rare for completion candidates to start with combining
> characters, so it's maybe not a bad tradeoff to dump that burden on the
> few completion tables where we know it's more likely to occur.
> 
> Still, if it can be done cheaply enough in `minibuffer.el`, it's much
> better, because the poor souls writing those completion tables are
> unlikely to be familiar with the issue and how best to circumvent it.

AFAIU, the problem happens when we insert two strings one after the
other in completion--insert:

    ;; If `str' is a list that has 2 elements,
    ;; then the second element is a suffix annotation.
    ;; If `str' has 3 elements, then the second element
    ;; is a prefix, and the third element is a suffix.
    (let* ((prefix (when (nth 2 str) (nth 1 str)))
           (suffix (or (nth 2 str) (nth 1 str))))
      (when prefix
        (let ((beg (point))
              (end (progn (insert prefix) (point))))
          (add-text-properties beg end `(mouse-face nil completion--string ,(car str)))))
      (completion--insert (car str) group-fun)
      (let ((beg (point))
            (end (progn (insert suffix) (point))))

We could handle the problem there, I think.