unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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)

      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).