unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#640: Forward: Buffer being killed not current in kill-buffer-hook
       [not found] <8763r1obx6.wl%max@openchat.com>
@ 2008-08-01 16:22 ` Max Mikhanosha
  2008-09-24 20:20   ` bug#640: marked as done (Forward: Buffer being killed not current in kill-buffer-hook ) Emacs bug Tracking System
  0 siblings, 1 reply; 2+ messages in thread
From: Max Mikhanosha @ 2008-08-01 16:22 UTC (permalink / raw)
  To: emacs-pretest-bug

[-- Attachment #1: Type: text/plain, Size: 110 bytes --]

I posted this to emacs-dev, but there was no response. This is still
happenning to me with latest CVS build.


[-- Attachment #2: Type: message/rfc822, Size: 2456 bytes --]

From: Max Mikhanosha <max@openchat.com>
To: emacs-devel@gnu.org
Subject: Buffer being killed not current in kill-buffer-hook
Date: Sat, 19 Jul 2008 16:29:25 -0400
Message-ID: <8763r1obx6.wl%max@openchat.com>

When using multi-tty emacsclient, the following piece of code demostrates the problem:

DISPLAY is unset, CVS Emacs started with --no-init-file

(require 'server)
(progn (setq server-name "test")
       (server-start))
(defun print-current-buffer ()
  (message "current-buffer=%s" (current-buffer)))
(add-hook 'kill-buffer-hook 'print-current-buffer)

Now from a different screen session, connect with emacsclient like so:
"lib-src/emacsclient -c -s test foo". New tty frame will be created. 
Immeditely kill the buffer, it will ask "Buffer has existing clients"
say "yes". emacsclient will disconnect from a server.

In the *Messages* buffer on the server frame:

When done with a buffer, type C-x #
(No files need saving)
current-buffer=*scratch*

All the code that uses kill-buffer-hook rightfully assumes that the
buffer being killed will be current buffer when called, as that is
what is stated in the kill-buffer-hook documentation. For example
saveplace does not work because of this.. ERC leaves a channel if 
unrelated buffer is killed on a different terminal, etc.

I had fixed this with the following patch, altho I don't know enough
about server.el logic to figure out if what it does is ok? Seems to
have fixed the bug and not broke anything else:

Index: lisp/server.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/server.el,v
retrieving revision 1.166
diff -u -b -r1.166 server.el
--- lisp/server.el	6 May 2008 07:57:49 -0000	1.166
+++ lisp/server.el	19 Jul 2008 20:28:26 -0000
@@ -1084,7 +1084,8 @@
 	  ;; tell it that it is done, and forget it entirely.
 	  (unless buffers
 	    (server-log "Close" proc)
-	    (server-delete-client proc)))))
+            (save-current-buffer 
+              (server-delete-client proc))))))
     (when (and (bufferp buffer) (buffer-name buffer))
       ;; We may or may not kill this buffer;
       ;; if we do, do not call server-buffer-done recursively


^ permalink raw reply	[flat|nested] 2+ messages in thread

* bug#640: marked as done (Forward: Buffer being killed not current in kill-buffer-hook )
  2008-08-01 16:22 ` bug#640: Forward: Buffer being killed not current in kill-buffer-hook Max Mikhanosha
@ 2008-09-24 20:20   ` Emacs bug Tracking System
  0 siblings, 0 replies; 2+ messages in thread
From: Emacs bug Tracking System @ 2008-09-24 20:20 UTC (permalink / raw)
  To: Chong Yidong

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]


Your message dated Wed, 24 Sep 2008 16:14:17 -0400
with message-id <8763oluwrq.fsf@cyd.mit.edu>
and subject line Re: Buffer being killed not current in kill-buffer-hook 
has caused the Emacs bug report #640,
regarding Forward: Buffer being killed not current in kill-buffer-hook 
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
640: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=640
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4944 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 110 bytes --]

I posted this to emacs-dev, but there was no response. This is still
happenning to me with latest CVS build.


[-- Attachment #2.1.2: Type: message/rfc822, Size: 2456 bytes --]

From: Max Mikhanosha <max@openchat.com>
To: emacs-devel@gnu.org
Subject: Buffer being killed not current in kill-buffer-hook
Date: Sat, 19 Jul 2008 16:29:25 -0400
Message-ID: <8763r1obx6.wl%max@openchat.com>

When using multi-tty emacsclient, the following piece of code demostrates the problem:

DISPLAY is unset, CVS Emacs started with --no-init-file

(require 'server)
(progn (setq server-name "test")
       (server-start))
(defun print-current-buffer ()
  (message "current-buffer=%s" (current-buffer)))
(add-hook 'kill-buffer-hook 'print-current-buffer)

Now from a different screen session, connect with emacsclient like so:
"lib-src/emacsclient -c -s test foo". New tty frame will be created. 
Immeditely kill the buffer, it will ask "Buffer has existing clients"
say "yes". emacsclient will disconnect from a server.

In the *Messages* buffer on the server frame:

When done with a buffer, type C-x #
(No files need saving)
current-buffer=*scratch*

All the code that uses kill-buffer-hook rightfully assumes that the
buffer being killed will be current buffer when called, as that is
what is stated in the kill-buffer-hook documentation. For example
saveplace does not work because of this.. ERC leaves a channel if 
unrelated buffer is killed on a different terminal, etc.

I had fixed this with the following patch, altho I don't know enough
about server.el logic to figure out if what it does is ok? Seems to
have fixed the bug and not broke anything else:

Index: lisp/server.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/server.el,v
retrieving revision 1.166
diff -u -b -r1.166 server.el
--- lisp/server.el	6 May 2008 07:57:49 -0000	1.166
+++ lisp/server.el	19 Jul 2008 20:28:26 -0000
@@ -1084,7 +1084,8 @@
 	  ;; tell it that it is done, and forget it entirely.
 	  (unless buffers
 	    (server-log "Close" proc)
-	    (server-delete-client proc)))))
+            (save-current-buffer 
+              (server-delete-client proc))))))
     (when (and (bufferp buffer) (buffer-name buffer))
       ;; We may or may not kill this buffer;
       ;; if we do, do not call server-buffer-done recursively


[-- Attachment #3: Type: message/rfc822, Size: 1302 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: Max Mikhanosha <max@openchat.com>
Cc: 640-done@emacsbugs.donarmstrong.com
Subject: Re: Buffer being killed not current in kill-buffer-hook
Date: Wed, 24 Sep 2008 16:14:17 -0400
Message-ID: <8763oluwrq.fsf@cyd.mit.edu>

> I posted this to emacs-dev, but there was no response. This is still
> happenning to me with latest CVS build.

Sorry for the delay.  I've just checked in a slightly more conservative
version of you patch (since I'm not sure it's correct to apply
save-current-buffer in all situations).  Thanks for the report and the
patch.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-09-24 20:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <8763r1obx6.wl%max@openchat.com>
2008-08-01 16:22 ` bug#640: Forward: Buffer being killed not current in kill-buffer-hook Max Mikhanosha
2008-09-24 20:20   ` bug#640: marked as done (Forward: Buffer being killed not current in kill-buffer-hook ) Emacs bug Tracking System

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).