GNU bug report logs - #10708
24.0.93; desktop.el doesn't restore buffers visiting files in archives

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Fri, 3 Feb 2012 10:05:02 UTC

Severity: wishlist

Found in version 24.0.93

To reply to this bug, email your comments to 10708 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#10708; Package emacs. (Fri, 03 Feb 2012 10:05:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Eli Zaretskii <eliz <at> gnu.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 03 Feb 2012 10:05:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.93; desktop.el doesn't restore buffers visiting files in archives
Date: Fri, 03 Feb 2012 05:03:05 -0500
 emacs -Q
 C-x C-f emacs-24.0.93.tar.gz  ;; or any other archive
 <in the file listing, go to the line of some file and type RET>
 M-x desktop-save RET RET
 C-x C-c

 emacs -Q
 M-: (desktop-read "/directory/where/you/saved/it/above") RET

Expected result: buffers for both the tarball and the file you were
looking at when you typed "C-x C-c" above are restored.

Actual result: the buffer with the tarball is restored, but the buffer
with its member is not.  A message in the echo area tells that 1 buffer
"failed to restore".  In *Messages*, you will see a message saying
something like

  Desktop: File "/home/e/eliz/emacs-24.x/emacs-24.0.93.tar.gz!emacs-24.0.93/lib/strftime.h" no longer exists.

IOW, desktop.el does not realize that this form of file names means an
archive member, and therefore does not extract that member when
restoring the desktop.


In GNU Emacs 24.0.93.3 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2012-02-02 on fencepost.gnu.org
Configured using:
 `configure '--enable-asserts' '--enable-checking' '--with-gif=no'
 '--with-tiff=no' 'CFLAGS=-O0 -ggdb -g3 -DGLYPH_DEBUG=1''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC [ > 0 ; 1 3 6 ; 0 c ( d e s k t o p - r e a d SPC 
" ~ / e m a c s - 2 4 . x " ) C-j y C-x b * M e s TAB 
RET ESC x r e p o r t - e m TAB RET

Recent messages:
("./bzr/emacs/trunk/src/emacs")
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading cc-mode...done
Desktop: File "/home/e/eliz/emacs-24.x/emacs-24.0.93.tar.gz!emacs-24.0.93/lib/strftime.h" no longer exists.
Loading tar-mode...done
File emacs-24.0.93.tar.gz is large (48MB), really open? (y or n)  y
uncompressing emacs-24.0.93.tar.gz...done
Parsing tar file...done
Wrote /home/e/eliz/emacs-24.x/.emacs.desktop.lock
Desktop: 1 buffer restored, 1 failed to restore.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug jka-compr tar-mode cc-mode cc-fonts easymenu cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt desktop
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dynamic-setting font-render-setting move-toolbar
gtk x-toolkit x multi-tty emacs)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10708; Package emacs. (Fri, 03 Feb 2012 13:40:02 GMT) Full text and rfc822 format available.

Message #8 received at 10708 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10708 <at> debbugs.gnu.org
Subject: Re: bug#10708: 24.0.93;
	desktop.el doesn't restore buffers visiting files in archives
Date: Fri, 03 Feb 2012 08:39:02 -0500
> IOW, desktop.el does not realize that this form of file names means an
> archive member, and therefore does not extract that member when
> restoring the desktop.

Of course, the "right" fix is to implement a file-name-handler
for tarballs (and other archives),


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10708; Package emacs. (Fri, 03 Feb 2012 14:49:01 GMT) Full text and rfc822 format available.

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#10708: 24.0.93; desktop.el doesn't restore buffers visiting
	files in archives
Date: Fri, 03 Feb 2012 07:48:03 -0700
On 2/3/12 6:39 AM, Stefan Monnier wrote:
>> IOW, desktop.el does not realize that this form of file names means an
>> archive member, and therefore does not extract that member when
>> restoring the desktop.
>
> Of course, the "right" fix is to implement a file-name-handler
> for tarballs (and other archives),

Is "archive!member" a good syntax?  i.e. what about regular files that have "!"
in their name?  (not to mention archives or archive members that have "!" in
their name)

-- 
Kevin Rodgers
Denver, Colorado, USA





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10708; Package emacs. (Fri, 03 Feb 2012 15:47:02 GMT) Full text and rfc822 format available.

Message #14 received at 10708 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
Cc: 10708 <at> debbugs.gnu.org
Subject: Re: bug#10708: 24.0.93;
	desktop.el doesn't restore buffers visiting files in archives
Date: Fri, 03 Feb 2012 17:45:55 +0200
> From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
> Date: Fri, 03 Feb 2012 07:48:03 -0700
> 
> On 2/3/12 6:39 AM, Stefan Monnier wrote:
> >> IOW, desktop.el does not realize that this form of file names means an
> >> archive member, and therefore does not extract that member when
> >> restoring the desktop.
> >
> > Of course, the "right" fix is to implement a file-name-handler
> > for tarballs (and other archives),
> 
> Is "archive!member" a good syntax?

We are using it for a long time, and no one ever complained.

> i.e. what about regular files that have "!"  in their name?

desktop.el will need to look for a literal file first, and only then
for an archive member.

> (not to mention archives or archive members that have "!" in their
> name)

That is already handled, AFAIR.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#10708; Package emacs. (Fri, 03 Feb 2012 16:14:02 GMT) Full text and rfc822 format available.

Message #17 received at 10708 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10708 <at> debbugs.gnu.org, Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
Subject: Re: bug#10708: 24.0.93;
	desktop.el doesn't restore buffers visiting files in archives
Date: Fri, 03 Feb 2012 11:13:09 -0500
>> >> IOW, desktop.el does not realize that this form of file names means an
>> >> archive member, and therefore does not extract that member when
>> >> restoring the desktop.
>> > Of course, the "right" fix is to implement a file-name-handler
>> > for tarballs (and other archives),
>> Is "archive!member" a good syntax?

I don't know.

> We are using it for a long time, and no one ever complained.

That's because currently we don't handle such files specially, but with
a file-name-handler for it we would need to be careful not to trigger
the file-handler for non-archives.


        Stefan




This bug report was last modified 13 years and 132 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.