From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.bugs Subject: bug#4061: 23.1.50; C-x C-v and saveplace Date: Fri, 04 Sep 2009 17:39:02 -0400 Message-ID: <87k50e8k5l.fsf@red-bean.com> References: <87vdkok2vo.fsf@cyd.mit.edu> Reply-To: Karl Fogel , 4061@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1252100839 2762 80.91.229.12 (4 Sep 2009 21:47:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Sep 2009 21:47:19 +0000 (UTC) Cc: Leo To: 4061@emacsbugs.donarmstrong.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 04 23:47:12 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Mjgch-00027A-Uj for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Sep 2009 23:47:12 +0200 Original-Received: from localhost ([127.0.0.1]:33405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mjgch-0006ax-A5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Sep 2009 17:47:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mjgcc-0006aT-JR for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2009 17:47:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjgcX-0006Zw-22 for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2009 17:47:05 -0400 Original-Received: from [199.232.76.173] (port=37634 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjgcW-0006Zt-Sq for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2009 17:47:00 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:52869) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MjgcW-0005pi-9P for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2009 17:47:00 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n84LkwOr012566; Fri, 4 Sep 2009 14:46:58 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n84Lj58M012119; Fri, 4 Sep 2009 14:45:05 -0700 Resent-Date: Fri, 4 Sep 2009 14:45:05 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Karl Fogel Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Fri, 04 Sep 2009 21:45:05 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4061 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4061-submit@emacsbugs.donarmstrong.com id=B4061.125210034610939 (code B ref 4061); Fri, 04 Sep 2009 21:45:05 +0000 Original-Received: (at 4061) by emacsbugs.donarmstrong.com; 4 Sep 2009 21:39:06 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from sanpietro.red-bean.com (Debian-exim@sanpietro.red-bean.com [66.146.206.141]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n84Ld4wr010936 for <4061@emacsbugs.donarmstrong.com>; Fri, 4 Sep 2009 14:39:05 -0700 Original-Received: from localhost ([127.0.0.1]:59744 helo=kfogel-work ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.69) (envelope-from ) id 1MjgUq-0006YV-2L; Fri, 04 Sep 2009 16:39:04 -0500 In-Reply-To: <87vdkok2vo.fsf@cyd.mit.edu> (Chong Yidong's message of "Sat, 15 Aug 2009 20:40:11 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Fri, 04 Sep 2009 17:47:05 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:30808 Archived-At: 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.