GNU bug report logs -
#49043
27.1: ibuffer-toggle-filter-group [BUGFIX]
Previous Next
Reported by: Boruch Baum <boruch_baum <at> gmx.com>
Date: Tue, 15 Jun 2021 15:53:02 UTC
Severity: normal
Tags: patch
Merged with 49030
Found in versions 27.1, 28.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49043 in the body.
You can then email your comments to 49043 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#49043
; Package
emacs
.
(Tue, 15 Jun 2021 15:53:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Boruch Baum <boruch_baum <at> gmx.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 15 Jun 2021 15:53:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I've been having operation ibuffer-toggle-filter-group reliably crash
whenever performed due to it trying to operate on a point beyond
point-max. The culprit seems to be in function ibuffer-map-lines where:
(delete-region (line-beginning-position)
(line-end-position))))
is being performed instead of:
(delete-region (line-beginning-position)
(min (point-max) (1+ (line-end-position))))
This solves the issue for me.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Tue, 15 Jun 2021 16:16:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 49043 <at> debbugs.gnu.org (full text, mbox):
Boruch Baum <boruch_baum <at> gmx.com> writes:
> I've been having operation ibuffer-toggle-filter-group reliably crash
> whenever performed due to it trying to operate on a point beyond
> point-max. The culprit seems to be in function ibuffer-map-lines where:
>
> (delete-region (line-beginning-position)
> (line-end-position))))
What does the crash look like?
It's rather surprising, because I don't think `line-end-position' can
ever return a position that's larger than `point-max'.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Tue, 15 Jun 2021 16:22:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 49043 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 15 Jun 2021 11:52:31 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
>
> I've been having operation ibuffer-toggle-filter-group reliably crash
> whenever performed due to it trying to operate on a point beyond
> point-max.
By "crash" do you mean it signals an error? Or a real crash with a
core dump?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Tue, 15 Jun 2021 20:14:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 49043 <at> debbugs.gnu.org (full text, mbox):
On 2021-06-15 19:20, Eli Zaretskii wrote:
> By "crash" do you mean it signals an error? Or a real crash with a
> core dump?
Sorry. It produced a backtrace, though I'm pretty sure I didn't have
toggle-debug-on-error set, so it was a surprise to get that. The
backtrace pointed to a call of function delete-region with a bounds
check problem. I saw that the upper-bound exceeded point-max, put in the
check, and voila.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Tue, 15 Jun 2021 20:20:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 49043 <at> debbugs.gnu.org (full text, mbox):
On 2021-06-15 18:15, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum <at> gmx.com> writes:
>
> > I've been having operation ibuffer-toggle-filter-group reliably crash
> > whenever performed due to it trying to operate on a point beyond
> > point-max. The culprit seems to be in function ibuffer-map-lines where:
> >
> > (delete-region (line-beginning-position)
> > (line-end-position))))
Oops. I misquoted the code (because I had submitted the report after I
had made/tested/byte-compiled/over-writte my only local copy). If you look at the
code on the gnu cgit instance, at line 1907, you'll see that it adds one
to the line-end-position before passing the value the function
delete-region.
A similar idiom exists on line 1843, so that may be another bug.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Tue, 15 Jun 2021 20:40:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 49043 <at> debbugs.gnu.org (full text, mbox):
It struck me just now to perform an rzgrep on the debian emacs 27 lisp
directory for the idiom "(1+ (line-end-position)"...
./calendar/todo-mode.el.gz:4254: (1+ (line-end-position)))
./calendar/todo-mode.el.gz:4273: (delete-region (line-beginning-position) (1+ (line-end-position)))
./calendar/todo-mode.el.gz:4332: (1+ (line-end-position))))
./calendar/todo-mode.el.gz:4683: (delete-region (line-beginning-position) (1+ (line-end-position)))
./calendar/todo-mode.el.gz:4924: (setq cat-begin (1+ (line-end-position)))
./international/quail.el.gz:2646: (1+ (line-end-position)))))))
./international/quail.el.gz:2650: (delete-region (point) (1+ (line-end-position)))
./dired.el.gz:1479: (1+ (line-end-position))
./gnus/nnimap.el.gz:277: (1+ (line-end-position)))
./obsolete/otodo-mode.el.gz:450: (let ((begin (1+ (line-end-position))))
./ibuffer.el.gz:1966: (delete-region (point) (1+ (line-end-position)))
./ibuffer.el.gz:2030: (min (point-max) (1+ (line-end-position))))
./emacs-lisp/smie.el.gz:1457: (1+ (line-end-position)) t))
./emacs-lisp/tabulated-list.el.gz:590: (delete-region (line-beginning-position) (1+ (line-end-position)))
./progmodes/dcl-mode.el.gz:802: (let* ((default-limit (1+ (line-end-position)))
./eshell/em-unix.el.gz:646: (point) (min (1+ (line-end-position))
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Wed, 16 Jun 2021 08:20:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 49043 <at> debbugs.gnu.org (full text, mbox):
Boruch Baum <boruch_baum <at> gmx.com> writes:
> Oops. I misquoted the code (because I had submitted the report after I
> had made/tested/byte-compiled/over-writte my only local copy). If you look at the
> code on the gnu cgit instance, at line 1907, you'll see that it adds one
> to the line-end-position before passing the value the function
> delete-region.
Right -- so I guess the problem here is that the last line of the buffer
doesn't have a newline... but skimming the code (I'm not super-familiar
with ibuffer), it seems like the final non-newline line is a summary
line and should be kept out of the sorting/filtering process? (If
there's a "buffer line" without a newline, it'll mess up the display
after filtering.)
So I think that perhaps the bug is somewhere else, but it's hard to say
without a recipe that reproduces the bug.
Do you have a test case?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Wed, 16 Jun 2021 08:27:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 49043 <at> debbugs.gnu.org (full text, mbox):
On 2021-06-16 10:19, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum <at> gmx.com> writes:
>
> Do you have a test case?
I *did* before I fixed it locally with the change, and filed the report.
Another approach to consider would be to put bounds-checking in function
delete-region against (point-min) and (point-max).
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Wed, 16 Jun 2021 08:52:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 49043 <at> debbugs.gnu.org (full text, mbox):
Boruch Baum <boruch_baum <at> gmx.com> writes:
> I *did* before I fixed it locally with the change, and filed the report.
Can you undo the change and come up with a test case?
> Another approach to consider would be to put bounds-checking in function
> delete-region against (point-min) and (point-max).
No, not at all -- if you're giving out-of-bounds values to
delete-region, you have a bug somewhere.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Wed, 16 Jun 2021 12:05:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 49043 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 16 Jun 2021 04:26:01 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
> Cc: 49043 <at> debbugs.gnu.org
>
> Another approach to consider would be to put bounds-checking in function
> delete-region against (point-min) and (point-max).
delete-region already does include such checking, that's why you get
the backtrace: it signals an error.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Wed, 16 Jun 2021 17:02:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 49043 <at> debbugs.gnu.org (full text, mbox):
On 2021-06-16 15:04, Eli Zaretskii wrote:
> > Date: Wed, 16 Jun 2021 04:26:01 -0400
> > From: Boruch Baum <boruch_baum <at> gmx.com>
> > Cc: 49043 <at> debbugs.gnu.org
> >
> > Another approach to consider would be to put bounds-checking in function
> > delete-region against (point-min) and (point-max).
>
> delete-region already does include such checking, that's why you get
> the backtrace: it signals an error.
You've missed the point.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Wed, 16 Jun 2021 17:11:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 49043 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 16 Jun 2021 13:01:08 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
> Cc: larsi <at> gnus.org, 49043 <at> debbugs.gnu.org
>
> > > Another approach to consider would be to put bounds-checking in function
> > > delete-region against (point-min) and (point-max).
> >
> > delete-region already does include such checking, that's why you get
> > the backtrace: it signals an error.
>
> You've missed the point.
Sorry about that. Could you please point out what I missed?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Fri, 18 Jun 2021 14:12:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 49043 <at> debbugs.gnu.org (full text, mbox):
On Wed, 16 Jun 2021 10:19:23 +0200 Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Boruch Baum <boruch_baum <at> gmx.com> writes:
>
>> Oops. I misquoted the code (because I had submitted the report after I
>> had made/tested/byte-compiled/over-writte my only local copy). If you look at the
>> code on the gnu cgit instance, at line 1907, you'll see that it adds one
>> to the line-end-position before passing the value the function
>> delete-region.
>
> Right -- so I guess the problem here is that the last line of the buffer
> doesn't have a newline... but skimming the code (I'm not super-familiar
> with ibuffer), it seems like the final non-newline line is a summary
> line and should be kept out of the sorting/filtering process? (If
> there's a "buffer line" without a newline, it'll mess up the display
> after filtering.)
>
> So I think that perhaps the bug is somewhere else, but it's hard to say
> without a recipe that reproduces the bug.
>
> Do you have a test case?
I do. It's the result of an error being raised in Tramp. Here's the
recipe (reliably reproducible on
GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.29,
cairo version 1.17.4) of 2021-06-06 built on strobelfs
Repository revision: 218d2d1509673d8bc67014558a31f5d0da1be5c6
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
Configured using: 'configure --with-native-compilation 'CFLAGS=-Og -g3''
Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS
GSETTINGS HARFBUZZ JPEG LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB
):
0. emacs -Q
1. Create a nonempty ZIP file test.zip (content is irrelevant).
2. Visit the directory containing test.zip in Dired.
3. Type `M-x load-library RET dired-x RET'.
4. With point on the Dired line containing test.zip type `M-!', which
prompts with "! on test.zip {3 guesses} [unzip]:" and type RET to
execute unzip (this of course requires having the unzip program).
5. With point still on the test.zip line type `D' and at the prompt `y'
to delete the ZIP file.
=> This raises a file-error (see below), but the ZIP file is deleted.
6. Type `M-x ibuffer'.
=> This raises the error "tramp-error: Method ‘archive’ is not known."
7. In the *Ibuffer* buffer type `g'.
=> This raises the error "ibuffer-current-state-list: Args out of range:
#<buffer *Ibuffer*>, 280, 332".
The latter error is apparently what the OP reported, and it's because
the Ibuffer buffer is corrupted; here's what it looks like after step 7,
except for the last character `|', which I added to show EOB:
[ Default ]
% tmp 802 Dired by name /tmp/
*% *Messages* 754 Messages
% steve 4171 Dired by name ~/
*scratch* 145 Lisp Interaction
* *Shell Command ... 114 Fundamental
*tramp/archive ... 0 Fundamental |
In other words, as you deduced, the summary line is missing, so the
attempt to do delete-region errors out.
The corruption of the Ibuffer buffer is due to the error raised at step
6, which is triggered in ibuffer-redisplay-engine during the execution
of ibuffer-insert-filter-group. This errors prevent the subsequent
execution of ibuffer-update-title-and-summary, resulting in the above
corrupted Ibuffer display.
As for the error at step 5, which is the cause of the following errors,
it is raised in tramp-gvfs-maybe-open-connection. Here's what the
*Messages* buffer contains after step 5:
Deleting...
Waiting for git... [2 times]
Tramp: Opening connection for file%3A%2F%2F%2Ftmp%2Ftest.zip using archive...failed
file-error: org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code1 Error when getting information for file “/tmp/test.zip”: No such file or directory
Step 3 of the recipe is necessary to raise the above errors. I guess
dired-guess-shell-command triggers Tramp file handling. CCing Michael
Albinus, who should be able to solve the problem.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Sat, 19 Jun 2021 12:08:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 49043 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> I do. It's the result of an error being raised in Tramp. Here's the
> recipe (reliably reproducible on
Thanks for the thorough recipe -- I was able to reproduce the problem,
too.
> 6. Type `M-x ibuffer'.
> => This raises the error "tramp-error: Method ‘archive’ is not known."
Here's the backtrace for that:
Debugger entered--Lisp error: (user-error "Method ‘archive’ is not known.")
signal(user-error ("Method ‘archive’ is not known."))
tramp-error((tramp-file-name "archive" nil nil "file%3A%2F%2F%2Ftmp%2Ffoo.zip" nil "" nil) user-error "Method `%s' is not known." "archive")
apply(tramp-error (tramp-file-name "archive" nil nil "file%3A%2F%2F%2Ftmp%2Ffoo.zip" nil "" nil) user-error "Method `%s' is not known." "archive")
tramp-user-error((tramp-file-name "archive" nil nil "file%3A%2F%2F%2Ftmp%2Ffoo.zip" nil "" nil) "Method `%s' is not known." "archive")
tramp-dissect-file-name("/archive:file%3A%2F%2F%2Ftmp%2Ffoo.zip:")
tramp-file-name-handler(expand-file-name "" "/archive:file%3A%2F%2F%2Ftmp%2Ffoo.zip:")
file-name-case-insensitive-p("")
abbreviate-file-name("")
ibuffer--abbreviate-file-name("")
ibuffer-make-column-filename(#<buffer *tramp/archive file%3A%2F%2F%2Ftmp%2Ffoo.zip*> 32)
ibuffer-make-column-filename-and-process(#<buffer *tramp/archive file%3A%2F%2F%2Ftmp%2Ffoo.zip*> 32)
#f(compiled-function (buffer mark) #<bytecode 0xa9479abf87c6c30>)(#<buffer *tramp/archive file%3A%2F%2F%2Ftmp%2Ffoo.zip*> 32)
ibuffer-insert-buffer-line(#<buffer *tramp/archive file%3A%2F%2F%2Ftmp%2Ffoo.zip*> 32 #f(compiled-function (buffer mark) #<bytecode 0xa9479abf87c6c30>))
ibuffer-insert-filter-group("Default" "Default" "" #f(compi
ibuffer-redisplay-engine(((#<buffer tmp> . 32) (#<buffer *C
ibuffer-update(nil)
ibuffer(nil)
funcall-interactively(ibuffer nil)
> Step 3 of the recipe is necessary to raise the above errors. I guess
> dired-guess-shell-command triggers Tramp file handling. CCing Michael
> Albinus, who should be able to solve the problem.
3) does indeed seem to be a Tramp problem, but I wonder if ibuffer
should be more resilient here? That is, to avoid messing up the
ibuffer, we could do something like:
diff --git a/lisp/ibuffer.el b/lisp/ibuffer.el
index 9088f31053..73ddfb260c 100644
--- a/lisp/ibuffer.el
+++ b/lisp/ibuffer.el
@@ -1184,7 +1184,11 @@ ibuffer-buffer-file-name
(defun ibuffer--abbreviate-file-name (filename)
"Abbreviate FILENAME using `ibuffer-directory-abbrev-alist'."
(let ((directory-abbrev-alist ibuffer-directory-abbrev-alist))
- (abbreviate-file-name filename)))
+ (condition-case ()
+ ;; This may fail if the filename is a Tramp filename that is
+ ;; invalid.
+ (abbreviate-file-name filename)
+ (error filename))))
(define-ibuffer-op ibuffer-do-save ()
"Save marked buffers as with `save-buffer'."
Any comments?
(This would be in addition to actually fixing 3).)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) patch.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 19 Jun 2021 12:08:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Sat, 19 Jun 2021 12:14:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 49043 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Any comments?
I'm working on this, pls give me some time for analysis.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Sat, 19 Jun 2021 15:57:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 49043 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
Hi Steve,
> I do. It's the result of an error being raised in Tramp. Here's the
> recipe (reliably reproducible on
>
> GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.29,
> cairo version 1.17.4) of 2021-06-06 built on strobelfs
> Repository revision: 218d2d1509673d8bc67014558a31f5d0da1be5c6
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
> Configured using: 'configure --with-native-compilation 'CFLAGS=-Og -g3''
> Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS
> GSETTINGS HARFBUZZ JPEG LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP
> NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
> TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB
> ):
>
> 0. emacs -Q
> 1. Create a nonempty ZIP file test.zip (content is irrelevant).
> 2. Visit the directory containing test.zip in Dired.
> 3. Type `M-x load-library RET dired-x RET'.
> 4. With point on the Dired line containing test.zip type `M-!', which
> prompts with "! on test.zip {3 guesses} [unzip]:" and type RET to
> execute unzip (this of course requires having the unzip program).
> 5. With point still on the test.zip line type `D' and at the prompt `y'
> to delete the ZIP file.
> => This raises a file-error (see below), but the ZIP file is deleted.
> 6. Type `M-x ibuffer'.
> => This raises the error "tramp-error: Method ‘archive’ is not known."
> 7. In the *Ibuffer* buffer type `g'.
> => This raises the error "ibuffer-current-state-list: Args out of range:
> #<buffer *Ibuffer*>, 280, 332".
Thanks for this. Apparently, it is the same error as bug#49030, I'll
merge both. A fix will follow soon, pls check whether it works for you.
> Steve Berman
Best regards, Michael.
Merged 49030 49043.
Request was from
Michael Albinus <michael.albinus <at> gmx.de>
to
control <at> debbugs.gnu.org
.
(Sat, 19 Jun 2021 15:58:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Sat, 19 Jun 2021 19:57:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 49043 <at> debbugs.gnu.org (full text, mbox):
On Sat, 19 Jun 2021 17:56:24 +0200 Michael Albinus <michael.albinus <at> gmx.de> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> 0. emacs -Q
>> 1. Create a nonempty ZIP file test.zip (content is irrelevant).
>> 2. Visit the directory containing test.zip in Dired.
>> 3. Type `M-x load-library RET dired-x RET'.
>> 4. With point on the Dired line containing test.zip type `M-!', which
>> prompts with "! on test.zip {3 guesses} [unzip]:" and type RET to
>> execute unzip (this of course requires having the unzip program).
>> 5. With point still on the test.zip line type `D' and at the prompt `y'
>> to delete the ZIP file.
>> => This raises a file-error (see below), but the ZIP file is deleted.
>> 6. Type `M-x ibuffer'.
>> => This raises the error "tramp-error: Method ‘archive’ is not known."
>> 7. In the *Ibuffer* buffer type `g'.
>> => This raises the error "ibuffer-current-state-list: Args out of range:
>> #<buffer *Ibuffer*>, 280, 332".
>
> Thanks for this. Apparently, it is the same error as bug#49030, I'll
> merge both.
Ah, right, I saw that report but then unfortunately forgot about it; it
would have saved me quite a bit of time...
> A fix will follow soon, pls check whether it works for you.
Looking forward to it!
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Sat, 19 Jun 2021 21:42:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 49043 <at> debbugs.gnu.org (full text, mbox):
On Sat, 19 Jun 2021 17:56:24 +0200 Michael Albinus <michael.albinus <at> gmx.de> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
> Hi Steve,
>
>> I do. It's the result of an error being raised in Tramp. Here's the
>> recipe (reliably reproducible on
>>
>> GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.29,
>> cairo version 1.17.4) of 2021-06-06 built on strobelfs
>> Repository revision: 218d2d1509673d8bc67014558a31f5d0da1be5c6
>> Repository branch: master
>> Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
>> Configured using: 'configure --with-native-compilation 'CFLAGS=-Og -g3''
>> Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS
>> GSETTINGS HARFBUZZ JPEG LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP
>> NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
>> TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB
>> ):
>>
>> 0. emacs -Q
>> 1. Create a nonempty ZIP file test.zip (content is irrelevant).
>> 2. Visit the directory containing test.zip in Dired.
>> 3. Type `M-x load-library RET dired-x RET'.
>> 4. With point on the Dired line containing test.zip type `M-!', which
>> prompts with "! on test.zip {3 guesses} [unzip]:" and type RET to
>> execute unzip (this of course requires having the unzip program).
>> 5. With point still on the test.zip line type `D' and at the prompt `y'
>> to delete the ZIP file.
>> => This raises a file-error (see below), but the ZIP file is deleted.
>> 6. Type `M-x ibuffer'.
>> => This raises the error "tramp-error: Method ‘archive’ is not known."
>> 7. In the *Ibuffer* buffer type `g'.
>> => This raises the error "ibuffer-current-state-list: Args out of range:
>> #<buffer *Ibuffer*>, 280, 332".
>
> Thanks for this. Apparently, it is the same error as bug#49030, I'll
> merge both. A fix will follow soon, pls check whether it works for you.
I rebuilt with your patch, and confirm it fixes the error in step 5
above, and hence the subsequent errors do not occur. Thanks!
Since essentially my recipe was previously reported in bug#49030, I
think that bug can be closed. But before closing bug#49043, perhaps
Boruch Baum should chime in, since he only reported the problem in
Ibuffer. I showed this can be triggered by the Tramp bug, but perhaps
there are other triggers too, and if so some additional safeguard in
Ibuffer such as what Lars suggested may be appropriate.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Sun, 20 Jun 2021 08:13:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 49043 <at> debbugs.gnu.org (full text, mbox):
On 2021-06-19 23:41, Stephen Berman wrote:
> Since essentially my recipe was previously reported in bug#49030, I
> think that bug can be closed. But before closing bug#49043, perhaps
> Boruch Baum should chime in, since he only reported the problem in
> Ibuffer. I showed this can be triggered by the Tramp bug, but perhaps
> there are other triggers too, and if so some additional safeguard in
> Ibuffer such as what Lars suggested may be appropriate.
Thanks for figuring this out, Steve. Your recipe may be what happened to
me, but if so the steps were taken over the course of a few days. I
remember that at some point days ago I did see and ignore a 'method
archive' error.
I'm okay with closing this bug as is.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Sun, 20 Jun 2021 14:30:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 49043 <at> debbugs.gnu.org (full text, mbox):
Boruch Baum <boruch_baum <at> gmx.com> writes:
Hi Boruch,
> I'm okay with closing this bug as is.
Done for Emacs 28 (Tramp 2.5). Since there won't be another Emacs 27
release, the patch isn't merged in the emacs-27 branch.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49043
; Package
emacs
.
(Mon, 21 Jun 2021 12:26:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 49043 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> I showed this can be triggered by the Tramp bug, but perhaps
> there are other triggers too, and if so some additional safeguard in
> Ibuffer such as what Lars suggested may be appropriate.
I think Michael's fix should be sufficient here, after looking at this
again. `abbreviate-file-name' isn't supposed to bug out, so we'll see
breakages throughout Emacs if it does, so adding special code to ibuffer
in this case to handle it wouldn't be productive.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 28.1, send any further explanations to
49043 <at> debbugs.gnu.org and Boruch Baum <boruch_baum <at> gmx.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 21 Jun 2021 12:26:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 20 Jul 2021 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 274 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.