From: Karl Fogel <kfogel@red-bean.com>
To: 4061@emacsbugs.donarmstrong.com
Cc: Leo <sdl.web@gmail.com>
Subject: bug#4061: 23.1.50; C-x C-v and saveplace
Date: Fri, 04 Sep 2009 17:39:02 -0400 [thread overview]
Message-ID: <87k50e8k5l.fsf@red-bean.com> (raw)
In-Reply-To: <87vdkok2vo.fsf@cyd.mit.edu> (Chong Yidong's message of "Sat, 15 Aug 2009 20:40:11 -0400")
I know what causes this now. saveplace.el works like this:
(add-hook 'kill-buffer-hook 'save-place-to-alist)
Now, `save-place-to-alist' checks `buffer-file-name' and (properly) does
nothing if there is no associated file. Since `find-alternate-file'
unsets `buffer-file-name' after renaming the old buffer but before
killing it, that effectively makes `save-place-to-alist' a no-op in the
old buffer.
It's not even clear what the most desirable behavior is. For example,
in `find-alternate-file' (without my patch), if the old buffer is
modified, should we still save place before killing it? I think so; or
rather, I think we should do whatever saveplace.el does if one kills a
modified buffer the normal way.
I'm still thinking. My patch below isn't really the right thing (see
below for why), but I wanted to record this all here to remember it.
[[[
* emacs/emacs-cvs/lisp/files.el
(find-alternate-file): Restore certain state in the old buffer
before killing it, so that hooks behave as expected. This addresses
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4061.
NOTE: DRAFT PATCH ONLY, DO NOT COMMIT. With this patch, doing C-x C-v
in a modified buffer visiting a file causes the user to be prompted to
save buffer " **lose**" (see files.el:find-alternate-file for why)
after they have successfully found their new file. That is hardly a
desirable behavior.
I will post for others' thoughts on whether the original bug is a bug,
and if it is what is the best way to fix it.
]]]
[[[
* emacs/emacs-cvs/lisp/files.el
(find-alternate-file): Restore certain state in the old buffer
before killing it, so that hooks behave as expected. This addresses
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4061.
NOTE: DRAFT PATCH ONLY, DO NOT COMMIT. With this patch, doing C-x C-v
in a modified buffer visiting a file causes the user to be prompted to
save buffer " **lose**" (see files.el:find-alternate-file for why)
after they have successfully found their new file. That is hardly a
desirable behavior.
I will post for others' thoughts on whether the original bug is a bug,
and if it is what is the best way to fix it.
]]]
Index: lisp/files.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/files.el,v
retrieving revision 1.1076
diff -u -r1.1076 files.el
--- lisp/files.el 4 Sep 2009 03:18:11 -0000 1.1076
+++ lisp/files.el 4 Sep 2009 21:30:00 -0000
@@ -1507,17 +1507,24 @@
;; Likewise for dired buffers.
(setq dired-directory nil)
(find-file filename wildcards))
- (when (eq obuf (current-buffer))
- ;; This executes if find-file gets an error
- ;; and does not really find anything.
- ;; We put things back as they were.
- ;; If find-file actually finds something, we kill obuf below.
- (setq buffer-file-name ofile)
- (setq buffer-file-number onum)
- (setq buffer-file-truename otrue)
- (setq dired-directory odir)
- (lock-buffer)
- (rename-buffer oname)))
+ (progn
+ ;; There's some state that we want to restore in obuf before
+ ;; we kill obuf, whether find-file succeeded or not. For
+ ;; example, we restore buffer-file-name so that certain hooks
+ ;; (e.g., 'save-place-to-alist in 'kill-buffer-hook) can
+ ;; behave as expected.
+ (save-excursion
+ (set-buffer obuf)
+ (setq buffer-file-name ofile)
+ (setq buffer-file-number onum)
+ (setq buffer-file-truename otrue)
+ (setq dired-directory odir))
+ ;; On the other hand, if find-file got an error and did not
+ ;; really find anything, we want to put everything back as it
+ ;; was, including the lock and the buffer name.
+ (when (eq obuf (current-buffer))
+ (lock-buffer)
+ (rename-buffer oname))))
(unless (eq (current-buffer) obuf)
(with-current-buffer obuf
;; We already asked; don't ask again.
next prev parent reply other threads:[~2009-09-04 21:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-16 0:40 bug#4061: 23.1.50; C-x C-v and saveplace Chong Yidong
2009-08-16 16:11 ` Karl Fogel
2009-08-17 14:01 ` Leo
2009-09-04 21:39 ` Karl Fogel [this message]
2009-09-05 0:16 ` Leo
-- strict thread matches above, loose matches on Subject: below --
2009-08-06 3:29 Leo
2009-08-15 20:18 ` Leo
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=87k50e8k5l.fsf@red-bean.com \
--to=kfogel@red-bean.com \
--cc=4061@emacsbugs.donarmstrong.com \
--cc=sdl.web@gmail.com \
/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.