GNU bug report logs - #71419
30.0.50; Completion does not always highlight the "common part" corresponding to suffix

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#71419: closed (30.0.50; Completion does not always highlight
 the "common part" corresponding to suffix)
Date: Sat, 01 Mar 2025 02:07:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Fri, 28 Feb 2025 18:06:01 -0800
with message-id <CADwFkmmGmQnDntrjo95eaeEZSDuFL0gT_o3jGdM4aA5VmSLUrg <at> mail.gmail.com>
and subject line Re: bug#71419: 30.0.50; Completion does not always highlight the "common part" corresponding to suffix
has caused the debbugs.gnu.org bug report #71419,
regarding 30.0.50; Completion does not always highlight the "common part" corresponding to suffix
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
71419: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71419
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Completion does not always highlight the "common part"
 corresponding to suffix
Date: Sat, 8 Jun 2024 01:36:42 +0300

X-Debbugs-Cc: monnier <at> IRO.UMontreal.CA

For example:

1. Type

  (fo|-function

where | denotes the position of point.

2. C-M-i

You get 5 completions (the exact number is not important), where "fo" is
highlighted in all of them, but "function is not.

3. Move point to after "-" (meaning, just one character forward), press
C-M-i again (twice).

Completion expands the text to "(fo-|-function" (the addition might be
unimportant) and "function" is highlighted with the face
`completions-common-part' now, in all completions.

This seems inconsistent.

Also, highlighting is information. If it was more uniform, we could use
it to e.g. address the FIXME in completion-all-completions. Though
that's up for discussion, given that highlighting is inherently less
reliable than other methods we use. But it would be a non-breaking
change, OT2H.

WDYT?

In GNU Emacs 30.0.50 (build 28, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.18.0, Xaw scroll bars) of 2024-06-07 built on potemkin
Repository revision: b571c6571c8bc4c34569650104aee273c19cbfd4
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12302000
System Description: Ubuntu 23.10

[Message part 3 (message/rfc822, inline)]

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 71419-done <at> debbugs.gnu.org
Subject: Re: bug#71419: 30.0.50; Completion does not always highlight the
 "common part" corresponding to suffix
Date: Fri, 28 Feb 2025 18:06:01 -0800

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> On 10/06/2024 00:06, Stefan Monnier wrote:
>>> diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
>>> index f62cb2566b2..144cda8cfdc 100644
>>> --- a/lisp/minibuffer.el
>>> +++ b/lisp/minibuffer.el
>>> @@ -3816,7 +3816,7 @@ completion-basic-all-completions
>>>                               'point
>>>                               (substring afterpoint 0 (cdr bounds)))))
>>>            (all (completion-pcm--all-completions prefix pattern table pred)))
>>> -    (completion-hilit-commonality all point (car bounds))))
>>> +    (completion-pcm--hilit-commonality pattern all)))
>>>
>>>   ;;; Partial-completion-mode style completion.
>> Thanks for tracking it down.  It matches my expectation.
>
> Thanks, now fixed on master.

I'm therefore closing this bug report.

>
>>> But it would have been nice to be able to use it in the "progressive
>>>   improvement" kind of fashion: when the suffix and the other parts are
>>>   highlighted correctly, we do the right thing; if the style missed the
>>>   suffix highlighting, we do the other thing - and put the responsibility on
>>> the third party.
>> 🙂
>
> It could work like in the attached. I agree that it's somewhat brittle, though.
>
> If you're not in favor of installing this patch, what would be your preferred
> strategy for fixing bug#70968? We could try resurrecting the relevant part of
> Daniel's patch for completion-all-completions, but it means a fair amount of
> breakage. Or another dynamic variable similar to completion-lazy-hilit-fn...
>
> FWIW my interest here is how to better implement the same step in company-mode,
> but the default UI is a good common ground.

Previous Next

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