From: Dmitry Gutov <dmitry@gutov.dev>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 71419@debbugs.gnu.org
Subject: bug#71419: 30.0.50; Completion does not always highlight the "common part" corresponding to suffix
Date: Thu, 13 Jun 2024 02:57:43 +0300 [thread overview]
Message-ID: <8446cd2d-7f27-4742-8193-3d83e7ef5f21@gutov.dev> (raw)
In-Reply-To: <jwvy17drfnf.fsf-monnier+emacs@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
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.
>> 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.
[-- Attachment #2: completions--count-common-spans.diff --]
[-- Type: text/x-patch, Size: 1861 bytes --]
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 144cda8cfdc..d8952094196 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2551,6 +2551,25 @@ completions--after-change
(with-selected-window window
(completions--deselect)))))
+(defun completions--count-common-spans (str)
+ (let ((pos 0)
+ prev-pos
+ value
+ (sum 0))
+ (while pos
+ (when prev-pos
+ (cl-incf sum (- pos prev-pos)))
+ (if (and (setq value (get-text-property pos 'face str))
+ (if (listp value)
+ (memq 'completions-common-part value)
+ (eq 'completions-common-part value)))
+ (setq prev-pos pos)
+ (setq prev-pos nil))
+ (setq pos (next-single-property-change pos 'face str))
+ (when (and (not pos) prev-pos)
+ (cl-incf sum (- (length str) prev-pos))))
+ sum))
+
(defun minibuffer-completion-help (&optional start end)
"Display a list of possible completions of the current minibuffer contents."
(interactive)
@@ -2706,6 +2725,10 @@ minibuffer-completion-help
;; but that clashed with another existing marker.
(cl-decf (nth 1 base-position)
(- end start (length choice)))
+ ;; Completion style that doesn't match suffix.
+ (unless (> (completions--count-common-spans choice)
+ (- (point) start))
+ (setq end (point)))
;; FIXME: Use `md' to do quoting&terminator here.
(completion--replace start (min end (point-max)) choice)
(let* ((minibuffer-completion-table ctable)
prev parent reply other threads:[~2024-06-12 23:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-07 22:36 bug#71419: 30.0.50; Completion does not always highlight the "common part" corresponding to suffix Dmitry Gutov
2024-06-07 22:47 ` Dmitry Gutov
2024-06-09 13:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-09 20:38 ` Dmitry Gutov
2024-06-09 21:06 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-12 23:57 ` Dmitry Gutov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8446cd2d-7f27-4742-8193-3d83e7ef5f21@gutov.dev \
--to=dmitry@gutov.dev \
--cc=71419@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).