all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Juanma Barranquero" <lekktu@gmail.com>
To: "Stefan Monnier" <monnier@iro.umontreal.ca>
Cc: emacs-pretest-bug@gnu.org, Martin Fischer <parozusa@web.de>
Subject: Re: 22.1.90; desktop-save throws (error "No buffer named <uniquified buffername>")
Date: Fri, 8 Feb 2008 20:00:03 +0100	[thread overview]
Message-ID: <f7ccd24b0802081100x78cecab3j3e1d348f24475f15@mail.gmail.com> (raw)
In-Reply-To: <jwv3as3b8t4.fsf-monnier+emacs@gnu.org>

> Yuck!

Well, yeah, but let's not exaggerate...

> Could you explain what is the problem, so we can try and find
> a cleaner workaround?

The original problem was that desktop.el saved the uniquified names,
so afterwards (in subsequent invocations of Emacs) the names were
"uniquified" but not really managed by uniquify. You started with A/C
and B/C, saved, reloaded, deleted A/C and still had B/C (instead of
just C).

The fix is simple: save the base name of the buffer instead of the
uniquified one.

That was done by modifying the information returned by
`desktop-buffer-info', which is the information written to the desktop
file for each buffer.

That works fine, except that dired buffers are treated specially,
which triggers the OP problem.

When trying to decide whether a buffer has to be saved or not,
`desktop-save' passes the output of `desktop-buffer-info' to
`desktop-save-buffer-p', which in most cases only takes into account
the name of the visited file. For dired buffers, though, it also looks
at its second argument (the buffer name) to find the buffer. With my
previous change,that fails because the "buffer name" it gets is now
the base name, not the name of the real buffer (that was my mistake, I
didn't realize the special treatment of dired buffers).

Most fixes involve modifying the output of `desktop-buffer-info' to
return both the buffer-name and the base name; however, the list has
to be "fixed back" before saving it to the desktop. Or, alternatively,
you can opt *not* to modify the info list, and instead try to detect
whether the buffer is uniquify-managed at the point you're writing the
info list to the desktop; but that is also unclean because at that
point you shouldn't need to process any element of the list specially,
or know about its contents.

The cleanest fix would be to admit that the info list should have both
the buffer name and the base name. But that means bumping up the
version of the desktop file.

             Juanma




  reply	other threads:[~2008-02-08 19:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-06 16:12 22.1.90; desktop-save throws (error "No buffer named <uniquified buffername>") Martin Fischer
2008-02-07  0:23 ` Juanma Barranquero
2008-02-08 16:59 ` Juanma Barranquero
2008-02-08 18:30   ` Stefan Monnier
2008-02-08 19:00     ` Juanma Barranquero [this message]
2008-02-08 21:17       ` Stefan Monnier
2008-02-12  0:44         ` Juanma Barranquero
2008-02-12  3:39           ` Stefan Monnier
2008-02-12  4:15             ` Juanma Barranquero
2008-02-27 12:43 ` Martin Fischer
2008-02-27 12:48   ` Juanma Barranquero
2008-02-27 16:28     ` Juanma Barranquero
2008-02-27 21:18       ` Stefan Monnier
2008-02-27 22:17         ` Juanma Barranquero
2008-02-27 22:37           ` Stefan Monnier
2008-02-27 23:00             ` Juanma Barranquero
2008-02-28  1:54               ` Stefan Monnier
2008-02-28  9:14                 ` Juanma Barranquero
2008-02-28 17:09                   ` Stefan Monnier
2008-02-28 13:27   ` Martin Fischer
2008-02-28 16:29     ` Juanma Barranquero
2008-02-29 10:07       ` Martin Fischer
2008-02-29 10:49         ` Juanma Barranquero
2008-02-29 13:17           ` Martin Fischer
2008-02-29 14:24             ` Juanma Barranquero
2008-02-29 14:48               ` Jason Rumney
2008-02-29 15:03                 ` Juanma Barranquero
2008-02-29 15:16                   ` Lennart Borgman (gmail)
2008-02-29 15:19                     ` Juanma Barranquero

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f7ccd24b0802081100x78cecab3j3e1d348f24475f15@mail.gmail.com \
    --to=lekktu@gmail.com \
    --cc=emacs-pretest-bug@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=parozusa@web.de \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.