GNU bug report logs -
#52169
28.0.60; "Args out of range" when completing shell command
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52169 in the body.
You can then email your comments to 52169 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52169
; Package
emacs
.
(Sun, 28 Nov 2021 21:39:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 28 Nov 2021 21:39:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
This is sort of a garbage-in, garbage-out situation, so I'll just let
the reproducer speak for itself:
$ emacs -Q
M-! ./nosuchcommand C-b TAB
- In Emacs 27.1, this simply says "[No match]".
- In Emacs 28.0.60, this errors out:
> completion--some: Args out of range: "./nosuchcomma", 0, 14
I'm attaching the backtrace obtained with M-x toggle-debug-on-error.
I'm not on the most ideal setup for compiling ATM, so I apologize for
not bisecting this (and for not trying with 27.2; Debian stable only has
27.1); I'll get to it eventually if no-one beats me.
AFAICT it's not a very impactful issue; however, since Emacs now throws
an error where it didn't use to, I figure there's a somewhat subtle bug
here with consequences I can't quite evaluate.
Thanks for your time.
[args-out-of-range.bt (text/plain, attachment)]
[Message part 3 (text/plain, inline)]
In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
of 2021-11-26 built on hirondell
Repository revision: 11860f89a593a8cfe7efb94e86370bbbe4318fba
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)
Configured using:
'configure --with-xwidgets --with-cairo --with-gconf --with-xinput2'
Configured features:
ACL CAIRO DBUS FREETYPE GCONF GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52169
; Package
emacs
.
(Mon, 29 Nov 2021 15:27:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52169 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> $ emacs -Q
> M-! ./nosuchcommand C-b TAB
>
> - In Emacs 27.1, this simply says "[No match]".
> - In Emacs 28.0.60, this errors out:
>
>> completion--some: Args out of range: "./nosuchcomma", 0, 14
As far as I can tell, this comes from:
(defun completion-basic-try-completion (string table pred point)
[...]
(let* ((suffix (substring afterpoint (cdr bounds)))
(prefix (substring beforepoint 0 (car bounds)))
But the length of beforepoint (i.e., "./nosuchcomma") is 13, while (car
bounds) is 14.
I'm not sure how this all connects up, so I've added Stefan to the CCs.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52169
; Package
emacs
.
(Mon, 29 Nov 2021 22:57:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 52169 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> Hello,
>
> This is sort of a garbage-in, garbage-out situation, so I'll just let
> the reproducer speak for itself:
>
> $ emacs -Q
> M-! ./nosuchcommand C-b TAB
>
> - In Emacs 27.1, this simply says "[No match]".
> - In Emacs 28.0.60, this errors out:
>
>> completion--some: Args out of range: "./nosuchcomma", 0, 14
>
> I'm attaching the backtrace obtained with M-x toggle-debug-on-error.
>
> I'm not on the most ideal setup for compiling ATM, so I apologize for
> not bisecting this (and for not trying with 27.2; Debian stable only has
> 27.1); I'll get to it eventually if no-one beats me.
Alright, if I didn't botch the bisection, then we're looking at
2021-04-23 "Fix small bug in 'completion-table-subvert'." (3806d2168b).
Bisection session attached, FWIW.
[Message part 2 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52169
; Package
emacs
.
(Tue, 30 Nov 2021 17:11:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 52169 <at> debbugs.gnu.org (full text, mbox):
> I'm not sure how this all connects up, so I've added Stefan to the CCs.
I'll try and look at it ASAP,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52169
; Package
emacs
.
(Sat, 04 Dec 2021 05:10:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 52169 <at> debbugs.gnu.org (full text, mbox):
>> $ emacs -Q
>> M-! ./nosuchcommand C-b TAB
>>
>> - In Emacs 27.1, this simply says "[No match]".
>> - In Emacs 28.0.60, this errors out:
>>
>> > completion--some: Args out of range: "./nosuchcomma", 0, 14
Yuck!
This is one of those cases where the mismatch between the assumptions of
pcomplete and the featureset of minibuffer.el clash: `pcomplete-stub`
tells us we're completing "./nosuchcommand" but without telling us where
that string comes from in the buffer, so we fail to find
"./nosuchcommand" just before point (because the "d" is *after* point)
and thus fall back on the worst-case handler which doesn't behave well
at all here.
I pushed to `master` a fix for the immediate cause of the `Args out of
range` error, which seems to brings us back to Emacs-27's poor behavior.
Maybe it's good enough for `emacs-28` as well, but I have to think about
this problem a bit more.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52169
; Package
emacs
.
(Sat, 04 Dec 2021 17:17:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 52169 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> I pushed to `master` a fix for the immediate cause of the `Args out of
> range` error, which seems to brings us back to Emacs-27's poor behavior.
Can confirm, thanks!
> Maybe it's good enough for `emacs-28` as well, but I have to think about
> this problem a bit more.
OK; leaving this open for the time being then.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52169
; Package
emacs
.
(Mon, 06 Dec 2021 04:25:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 52169 <at> debbugs.gnu.org (full text, mbox):
Kévin Le Gouguec [2021-12-04 18:16:50] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I pushed to `master` a fix for the immediate cause of the `Args out of
>> range` error, which seems to brings us back to Emacs-27's poor behavior.
> Can confirm, thanks!
Thanks.
>> Maybe it's good enough for `emacs-28` as well, but I have to think about
>> this problem a bit more.
> OK; leaving this open for the time being then.
Hmm, I can't think of a good way to make it work correctly without
significant changes to `pcomplete.el` and its API.
For `emacs-28`, I propose the patch below, which is a slightly improved
version of the patch currently on `master`. As before, it won't fix the
real problem, but will avoid "Args out of range" and revert to the
behavior we had in Emacs-27 (which was/is broken, but tends
to be milder for the user).
Any objection?
Stefan
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index ca82b4a9e60..21d610fdf44 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -283,8 +283,9 @@ completion-table-subvert
((eq (car-safe action) 'boundaries)
(let ((beg (or (and (eq (car-safe res) 'boundaries) (cadr res)) 0)))
`(boundaries
- ,(max (length s1)
- (+ beg (- (length s1) (length s2))))
+ ,(min (length string)
+ (max (length s1)
+ (+ beg (- (length s1) (length s2)))))
. ,(and (eq (car-safe res) 'boundaries) (cddr res)))))
((stringp res)
(if (string-prefix-p s2 res completion-ignore-case)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52169
; Package
emacs
.
(Mon, 06 Dec 2021 05:16:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 52169 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> For `emacs-28`, I propose the patch below, which is a slightly improved
> version of the patch currently on `master`. As before, it won't fix the
> real problem, but will avoid "Args out of range" and revert to the
> behavior we had in Emacs-27 (which was/is broken, but tends
> to be milder for the user).
Sounds good to me.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52169
; Package
emacs
.
(Mon, 06 Dec 2021 12:57:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 52169 <at> debbugs.gnu.org (full text, mbox):
> Cc: 52169 <at> debbugs.gnu.org,
> Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Date: Sun, 05 Dec 2021 23:24:13 -0500
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> For `emacs-28`, I propose the patch below, which is a slightly improved
> version of the patch currently on `master`. As before, it won't fix the
> real problem, but will avoid "Args out of range" and revert to the
> behavior we had in Emacs-27 (which was/is broken, but tends
> to be milder for the user).
>
> Any objection?
Not from me, thanks.
Reply sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
You have taken responsibility.
(Mon, 06 Dec 2021 14:46:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
:
bug acknowledged by developer.
(Mon, 06 Dec 2021 14:46:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 52169-done <at> debbugs.gnu.org (full text, mbox):
>> Any objection?
> Not from me, thanks.
Pushed, thanks,
Stefan
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 04 Jan 2022 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 74 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.