unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@janestreet.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 62700@debbugs.gnu.org, sbaugh@catern.com, Juri Linkov <juri@linkov.net>
Subject: bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer
Date: Tue, 13 Jun 2023 16:59:19 -0400	[thread overview]
Message-ID: <ier8rcngjtk.fsf@janestreet.com> (raw)
In-Reply-To: <83352vwb6v.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 13 Jun 2023 19:59:04 +0300")

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Juri Linkov <juri@linkov.net>
>> Cc: sbaugh@janestreet.com,  62700@debbugs.gnu.org,  sbaugh@catern.com
>> Date: Tue, 13 Jun 2023 19:54:04 +0300
>> 
>> >> I checked that no problems occurred in minibuffer.el on the master branch.
>> >
>> > Thanks.  I wasn't sure that my manual resolution of the merge conflict
>> > in this case was correct.
>> 
>> I looked at the patch that should be pushed to master, and noticed
>> that probably it needs the same change that was applied in emacs-29.
>> Maybe Spencer could confirm what would be the right patch for master.
>
> Yes, Spencer, please take a look.

Indeed it needs the same change.  Here's the version of the patch that
should be pushed to master.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Handle-point-not-at-EOB-in-minibuffer-choose-complet.patch --]
[-- Type: text/x-patch, Size: 1696 bytes --]

From 4769e70e2e9af6eb68947d6c2ed0dcff0831def0 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
Date: Mon, 24 Apr 2023 10:05:24 -0400
Subject: [PATCH] Handle point not at EOB in minibuffer-choose-completion

Without this change, only the minibuffer contents before point are
cleared when a completion is chosen, which results in stray text when
point is in the middle of the minibuffer.

After this change, we heuristically decide either to clear the whole
buffer or only part of it, taking into account the location of point.

* lisp/minibuffer.el (minibuffer-completion-help): Use point when
calculating completion-base-affixes. (Bug#62700)
---
 lisp/minibuffer.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 539206a19e4..d079dc0bcdf 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2395,7 +2395,11 @@ minibuffer-completion-help
              (prefix (unless (zerop base-size) (substring string 0 base-size)))
              (base-prefix (buffer-substring (minibuffer--completion-prompt-end)
                                             (+ start base-size)))
-             (base-suffix (buffer-substring (point) (point-max)))
+             (base-suffix
+              (if (eq (alist-get 'category (cdr md)) 'file)
+                  (buffer-substring (save-excursion (or (search-forward "/" nil t) (point-max)))
+                                    (point-max))
+                ""))
              (all-md (completion--metadata (buffer-substring-no-properties
                                             start (point))
                                            base-size md
-- 
2.39.3


  reply	other threads:[~2023-06-13 20:59 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <b921ea5c-71a2-4e8f-b1cf-dd26831f8104@email.android.com>
2023-04-10 18:20 ` bug#62700: 29.0.60; minibuffer-{previous,next,choose}-completion behave unintuitively when point is not at end of buffer Juri Linkov
2023-04-20 16:52   ` Spencer Baugh
2023-04-20 18:18     ` Juri Linkov
2023-04-20 18:46       ` Spencer Baugh
2023-04-20 19:00         ` Eli Zaretskii
2023-04-21 18:56           ` sbaugh
2023-04-22 10:48             ` Eli Zaretskii
2023-04-22 12:57               ` sbaugh
2023-04-22 13:15                 ` Eli Zaretskii
2023-04-22 21:38                   ` sbaugh
2023-04-23  6:13                     ` Eli Zaretskii
2023-04-23 11:48                       ` sbaugh
2023-04-24 11:22                         ` Eli Zaretskii
2023-05-02 15:13               ` sbaugh
2023-05-02 17:57                 ` Eli Zaretskii
2023-05-08 15:48                   ` Juri Linkov
2023-05-08 16:11                     ` Eli Zaretskii
2023-06-03  0:58                       ` Spencer Baugh
2023-06-04  7:09                         ` Eli Zaretskii
2023-06-10 10:51                       ` Eli Zaretskii
2023-06-12 18:27                         ` Juri Linkov
2023-06-13  2:32                           ` Eli Zaretskii
2023-06-13 16:54                             ` Juri Linkov
2023-06-13 16:59                               ` Eli Zaretskii
2023-06-13 20:59                                 ` Spencer Baugh [this message]
2023-06-14 17:32                                   ` Juri Linkov
2023-09-03 17:37                                   ` Juri Linkov
2023-09-04  0:30                                     ` sbaugh
2023-09-04  6:51                                       ` Juri Linkov
2023-11-14  7:39                                     ` Juri Linkov
2023-11-15 17:42                                       ` Juri Linkov
2023-04-20 18:51       ` Eli Zaretskii
2023-04-06 17:56 Spencer Baugh
2023-04-06 18:22 ` Eli Zaretskii
2023-04-06 18:58   ` Spencer Baugh
2023-04-06 19:30     ` Eli Zaretskii
2023-04-06 20:42       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-06 18:55 ` Juri Linkov
2023-04-06 19:22   ` Spencer Baugh
2023-04-07 16:37     ` Juri Linkov
2023-04-07 21:02       ` sbaugh
2023-04-08  6:34         ` Eli Zaretskii
2023-04-08 10:58           ` sbaugh
2023-04-08 13:19             ` Eli Zaretskii
2023-04-08 18:36           ` Juri Linkov
2023-04-08 19:32             ` Eli Zaretskii
2023-04-09 16:40               ` Juri Linkov
2023-04-09 17:38                 ` Eli Zaretskii
2023-04-08 18:30         ` Juri Linkov
     [not found]   ` <ierbk6lup79.fsf@janestreet.com>
2024-04-07 17:16     ` Juri Linkov

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=ier8rcngjtk.fsf@janestreet.com \
    --to=sbaugh@janestreet.com \
    --cc=62700@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    --cc=sbaugh@catern.com \
    /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).