GNU bug report logs -
#71419
30.0.50; Completion does not always highlight the "common part" corresponding to suffix
Previous Next
Reported by: Dmitry Gutov <dmitry <at> gutov.dev>
Date: Fri, 7 Jun 2024 22:38:01 UTC
Severity: normal
Found in version 30.0.50
Done: Stefan Kangas <stefankangas <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#71419: 30.0.50; Completion does not always highlight the "common part" corresponding to suffix
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 71419 <at> debbugs.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)]
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.
[Message part 3 (message/rfc822, inline)]
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
This bug report was last modified 80 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.