unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 65089@debbugs.gnu.org, Augusto Stoffel <arstoffel@gmail.com>,
	Mauro Aranda <maurooaranda@gmail.com>
Subject: bug#65089: 30.0.50; shell-command filename completion unexpected behavior change
Date: Tue, 15 Aug 2023 10:59:14 -0400	[thread overview]
Message-ID: <jwvjztws75w.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83pm41sqbs.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Aug 2023 14:04:23 +0300")

>> Now, with emacs -Q:
>> M-!
>> ls ~/bug/bar
>> Put point between "/" and "b" of "bar" and type TAB
>> emacs says "No match", but I expected it to offer completions, foo-1 and
>> foo-2.
>> 
>> That was the behavior, at least in Emacs 28.  Reverting the following
>> commit, returns this behavior for me:

Hmm... I haven't tracked down why/how this worked before, but this is
a general problem with pcomplete when point is in the middle of
an argument.

The root cause is a problem in the API: `pcomplete-completions` (the
function that tries to figure out what it is we're trying to complete)
only tells us:

- you're trying to complete the string "~/bug/bar".
- the start position of the thing you're trying to complete (i.e. the
  point just before ~).
- the completion table.

In this case it seems obvious that the "~/bug/bar" returned is
the "~/bug/bar" found at the starting position, but in the general case,
the strings don't have to match and we have to make an educated guess
about how the returned string maps to the buffer contents (i.e. how
buffer positions map to positions within the string and vice-versa).

The patch below adds yet another heuristic to try and handle the
current case, but really we should rework the pcomplete API so as to
provide us the right info to start with.


        Stefan


diff --git a/lisp/pcomplete.el b/lisp/pcomplete.el
index c7ec228c1db..060ddc1d853 100644
--- a/lisp/pcomplete.el
+++ b/lisp/pcomplete.el
@@ -465,6 +465,8 @@ pcomplete-completions-at-point
            ;; rely less on c-t-subvert.
            (beg (max (- (point) (length pcomplete-stub))
                      argbeg))
+           (end (point))
+           tmp
            buftext)
       ;; Try and improve our guess of `beg' in case the difference
       ;; between pcomplete-stub and the buffer's text is simply due to
@@ -472,11 +474,19 @@ pcomplete-completions-at-point
       ;; indispensable but reduces the reliance on c-t-subvert and
       ;; improves corner case behaviors.
       (while (progn (setq buftext (pcomplete-unquote-argument
-                                   (buffer-substring beg (point))))
+                                   (buffer-substring beg end)))
                     (and (> beg argbeg)
                          (> (length pcomplete-stub) (length buftext))))
         (setq beg (max argbeg (- beg (- (length pcomplete-stub)
                                         (length buftext))))))
+      ;; Try and improve our guess of `end' in case it's not point.
+      (while (and (< (length buftext) (length pcomplete-stub))
+                  (< end (point-max))
+                  (string-prefix-p (setq tmp (pcomplete-unquote-argument
+                                              (buffer-substring beg (1+ end))))
+                                   pcomplete-stub))
+        (setq end (1+ end))
+        (setq buftext tmp))
       (when completions
         (let ((table
                (completion-table-with-quoting
@@ -510,7 +520,7 @@ pcomplete-completions-at-point
                            seen)))))))
           (when completion-ignore-case
             (setq table (completion-table-case-fold table)))
-          (list beg (point) table
+          (list beg end table
                 :annotation-function
                 (lambda (cand)
                   (when (stringp cand)






  parent reply	other threads:[~2023-08-15 14:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-05 10:46 bug#65089: 30.0.50; shell-command filename completion unexpected behavior change Mauro Aranda
2023-08-05 11:04 ` Eli Zaretskii
2023-08-12  6:51   ` Eli Zaretskii
2023-08-15 14:59   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-08-15 22:23     ` Mauro Aranda
2023-09-02 20:07       ` Stefan Kangas
2023-09-02 22:01         ` Mauro Aranda
2023-09-08 15:33         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-07 14:01           ` Mauro Aranda

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=jwvjztws75w.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=65089@debbugs.gnu.org \
    --cc=arstoffel@gmail.com \
    --cc=eliz@gnu.org \
    --cc=maurooaranda@gmail.com \
    --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).