From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#65089: 30.0.50; shell-command filename completion unexpected behavior change Date: Tue, 15 Aug 2023 10:59:14 -0400 Message-ID: References: <7e89aab4-41bb-384a-760d-9fd7830ff6b9@gmail.com> <83pm41sqbs.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17284"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 65089@debbugs.gnu.org, Augusto Stoffel , Mauro Aranda To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 15 17:00:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qVvWy-0004Dn-FB for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 15 Aug 2023 17:00:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qVvWh-0000Gq-Jf; Tue, 15 Aug 2023 11:00:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qVvWc-0000AD-Vy for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2023 11:00:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qVvWc-0008BJ-Lm for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2023 11:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qVvWc-0008S4-A6 for bug-gnu-emacs@gnu.org; Tue, 15 Aug 2023 11:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Aug 2023 15:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65089 X-GNU-PR-Package: emacs Original-Received: via spool by 65089-submit@debbugs.gnu.org id=B65089.169211156732407 (code B ref 65089); Tue, 15 Aug 2023 15:00:02 +0000 Original-Received: (at 65089) by debbugs.gnu.org; 15 Aug 2023 14:59:27 +0000 Original-Received: from localhost ([127.0.0.1]:36462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVvW3-0008Qd-F3 for submit@debbugs.gnu.org; Tue, 15 Aug 2023 10:59:27 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15128) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVvVy-0008QN-Qk for 65089@debbugs.gnu.org; Tue, 15 Aug 2023 10:59:25 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 29A4C444FAF; Tue, 15 Aug 2023 10:59:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1692111555; bh=19pnE+kuuGcmNPPiRonj0G/aKWmAQ6sxUtVW5MHENFw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=V9cJvSqwW+4Yb7xMn/+KO0y/Ojrmm9LIHWPig6PhxSVthXx6yVaJ8mmNXM6ZWSBDk ft2jofKnSdr2F8wKxi3XZWYAzVdH0zQv4uuRKFObljtvPIxSA1aK1BeBPKYxGLjiEe uByB4bApgyoay0LK1PNaobgWNeBZYYms8p0bGGPNhFwp/+W2CirhtH+7GIPXg/Mobj DVmlHwpilnMnzU33fIDSzJKgA4NfNK89JlkTdW6PTJDSAOdwW0bxWVi7dnHi5/VNlF 1bcb5/kwqUmNjRNe0jrnYxCwm2kHeK+usDduQ7Jb1mUW2KG5MgFELCFzBOA3Ok026t RcheWoj6rGhZQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 66662444FB5; Tue, 15 Aug 2023 10:59:15 -0400 (EDT) Original-Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 34B2B1202C4; Tue, 15 Aug 2023 10:59:15 -0400 (EDT) In-Reply-To: <83pm41sqbs.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 05 Aug 2023 14:04:23 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:267499 Archived-At: >> 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. >>=20 >> That was the behavior, at least in Emacs 28.=A0 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+ en= d)))) + 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)