all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 23.1: Is delete-windows-on supposed to change the current buffer?
@ 2009-07-30 22:13 Jeffrey C Honig
  2009-07-31  9:08 ` martin rudalics
  0 siblings, 1 reply; 7+ messages in thread
From: Jeffrey C Honig @ 2009-07-30 22:13 UTC (permalink / raw)
  To: emacs-devel

I'm debugging a problem with mh-e with 23.1.  In particular
(mh-yank-cur-msg) in lisp/mh-e/mh-letter.el.

In 23.1, unlike prior releases, this sequence changes the current
buffer:

          (if mh-delete-yanked-msg-window-flag
              (delete-windows-on mh-show-buffer)))

Is this change in behavior expected so that we should fix mh-e?  Or is
this a bug in emacs 23.1 that I should report?

Thanks (谢谢).

Jeff

-- 
Jeffrey C. Honig <jch@honig.net>
http://www.honig.net/jch
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>




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

* Re: 23.1: Is delete-windows-on supposed to change the current buffer?
  2009-07-30 22:13 23.1: Is delete-windows-on supposed to change the current buffer? Jeffrey C Honig
@ 2009-07-31  9:08 ` martin rudalics
  2009-07-31 15:49   ` Jeffrey C Honig
                     ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: martin rudalics @ 2009-07-31  9:08 UTC (permalink / raw)
  To: Jeffrey C Honig; +Cc: emacs-devel

 > I'm debugging a problem with mh-e with 23.1.  In particular
 > (mh-yank-cur-msg) in lisp/mh-e/mh-letter.el.
 >
 > In 23.1, unlike prior releases, this sequence changes the current
 > buffer:
 >
 >           (if mh-delete-yanked-msg-window-flag
 >               (delete-windows-on mh-show-buffer)))
 >
 > Is this change in behavior expected so that we should fix mh-e?  Or is
 > this a bug in emacs 23.1 that I should report?

What is your window configuration like before and after that form gets
executed?

`delete-windows-on' deletes all windows showing `mh-show-buffer'.  If,
for example, `mh-show-buffer' is shown in the selected window and that
window is the only window on its frame, and that frame is the only
frame, another buffer is shown in that window and becomes the current
buffer.  window_loop handles this as

		    if (EQ (window, selected_window))
		      Fset_buffer (w->buffer);

unchanged since the past release.  A similar behavior applies when the
frame can be deleted or there's another window on the frame.

Can you exclude that there was some change in the `mh-' part handling
this?

martin




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

* Re: 23.1: Is delete-windows-on supposed to change the current buffer?
  2009-07-31  9:08 ` martin rudalics
@ 2009-07-31 15:49   ` Jeffrey C Honig
  2009-07-31 16:11     ` martin rudalics
  2009-07-31 17:11   ` Bill Wohler
  2009-07-31 18:56   ` Stefan Monnier
  2 siblings, 1 reply; 7+ messages in thread
From: Jeffrey C Honig @ 2009-07-31 15:49 UTC (permalink / raw)
  To: martin rudalics; +Cc: emacs-devel

martin rudalics <rudalics@gmx.at> wrote:

> > I'm debugging a problem with mh-e with 23.1.  In particular
> > (mh-yank-cur-msg) in lisp/mh-e/mh-letter.el.
> >
> > In 23.1, unlike prior releases, this sequence changes the current
> > buffer:
> >
> >           (if mh-delete-yanked-msg-window-flag
> >               (delete-windows-on mh-show-buffer)))
> >
> > Is this change in behavior expected so that we should fix mh-e?  Or is
> > this a bug in emacs 23.1 that I should report?
> 
> What is your window configuration like before and after that form gets
> executed?

In my case (which is not standard mh-e as I pop up new frames for draft
buffers):

Before:
	Current buffer:
	     mh-sent-from-folder
	Main Frame:
	     mh-sent-from-folder
	     mh-show-buffer
	New Frame:
	    draft-1

After:
	Current buffer:
	     draft-1
	Main Frame:
	     mh-sent-from-folder
	New Frame
	    draft-1

So the surprise is that the current buffer changed at all.

The issue with the current buffer changing is that we are relying on
mh-show-buffer not changing, which is a buffer local variable.

This is easy to fix in mh-e.  But if this is an unexpected change in the
behavior of emacs it should probably be fixed there instead.

> `delete-windows-on' deletes all windows showing `mh-show-buffer'.  If,
> for example, `mh-show-buffer' is shown in the selected window and that
> window is the only window on its frame, and that frame is the only
> frame, another buffer is shown in that window and becomes the current
> buffer.  window_loop handles this as
> 
> 		    if (EQ (window, selected_window))
> 		      Fset_buffer (w->buffer);
> 
> unchanged since the past release.  A similar behavior applies when the
> frame can be deleted or there's another window on the frame.
> 
> Can you exclude that there was some change in the `mh-' part handling
> this?

This code has not changed in three years, so yes, something has changed
in emacs.

I've also been running the current mh-e code (from emacs CVS) with emacs
22 up until yesterday).

Thanks (谢谢).

Jeff

-- 
Jeffrey C. Honig <jch@honig.net>
http://www.honig.net/jch
GnuPG ID:14E29E13 <http://www.honig.net/jch/key.shtml>




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

* Re: 23.1: Is delete-windows-on supposed to change the current buffer?
  2009-07-31 15:49   ` Jeffrey C Honig
@ 2009-07-31 16:11     ` martin rudalics
  0 siblings, 0 replies; 7+ messages in thread
From: martin rudalics @ 2009-07-31 16:11 UTC (permalink / raw)
  To: Jeffrey C Honig; +Cc: emacs-devel

 > In my case (which is not standard mh-e as I pop up new frames for draft
 > buffers):
 >
 > Before:
 > 	Current buffer:
 > 	     mh-sent-from-folder
 > 	Main Frame:
 > 	     mh-sent-from-folder
 > 	     mh-show-buffer
 > 	New Frame:
 > 	    draft-1
 >
 > After:
 > 	Current buffer:
 > 	     draft-1
 > 	Main Frame:
 > 	     mh-sent-from-folder
 > 	New Frame
 > 	    draft-1
 >
 > So the surprise is that the current buffer changed at all.
 >
 > The issue with the current buffer changing is that we are relying on
 > mh-show-buffer not changing, which is a buffer local variable.
 >
 > This is easy to fix in mh-e.  But if this is an unexpected change in the
 > behavior of emacs it should probably be fixed there instead.

Is the window showing `mh-show-buffer' selected when you execute your
form?  Also what happens when you do C-x 0 in the window showing
`mh-show-buffer'?  Is the "After" configuration the same as above?

All this might be related to bug#3949 Lennart spotted recently.

martin




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

* Re: 23.1: Is delete-windows-on supposed to change the current buffer?
  2009-07-31  9:08 ` martin rudalics
  2009-07-31 15:49   ` Jeffrey C Honig
@ 2009-07-31 17:11   ` Bill Wohler
  2009-07-31 18:56   ` Stefan Monnier
  2 siblings, 0 replies; 7+ messages in thread
From: Bill Wohler @ 2009-07-31 17:11 UTC (permalink / raw)
  To: emacs-devel

martin rudalics <rudalics@gmx.at> writes:

> Can you exclude that there was some change in the `mh-' part handling
> this?

That code was last touched 7 years ago...

Thanks for your reply--I hope you and Jeff can get to the root of this!

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD





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

* Re: 23.1: Is delete-windows-on supposed to change the current buffer?
  2009-07-31  9:08 ` martin rudalics
  2009-07-31 15:49   ` Jeffrey C Honig
  2009-07-31 17:11   ` Bill Wohler
@ 2009-07-31 18:56   ` Stefan Monnier
  2009-07-31 20:17     ` Bill Wohler
  2 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2009-07-31 18:56 UTC (permalink / raw)
  To: martin rudalics; +Cc: Jeffrey C Honig, emacs-devel

> `delete-windows-on' deletes all windows showing `mh-show-buffer'.  If,
> for example, `mh-show-buffer' is shown in the selected window and that
> window is the only window on its frame, and that frame is the only
> frame, another buffer is shown in that window and becomes the current
> buffer.  window_loop handles this as

> 		    if (EQ (window, selected_window))
> 		      Fset_buffer (w->buffer);

> unchanged since the past release.

My guess is that the switch from Fdisplay_buffer to the Elisp version of
code, causes the windows to be created slightly differently, and this in
turn causes delete-windows-on in this particular case to cycle through
the windows in a different order.
In any case, the answer is that delete-windows-on should be expected to
change the current-buffer, so if you want it to stay unchanged, you need
save-excursion.


        Stefan




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

* Re: 23.1: Is delete-windows-on supposed to change the current buffer?
  2009-07-31 18:56   ` Stefan Monnier
@ 2009-07-31 20:17     ` Bill Wohler
  0 siblings, 0 replies; 7+ messages in thread
From: Bill Wohler @ 2009-07-31 20:17 UTC (permalink / raw)
  To: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> `delete-windows-on' deletes all windows showing `mh-show-buffer'.  If,
>> for example, `mh-show-buffer' is shown in the selected window and that
>> window is the only window on its frame, and that frame is the only
>> frame, another buffer is shown in that window and becomes the current
>> buffer.  window_loop handles this as
>
>> 		    if (EQ (window, selected_window))
>> 		      Fset_buffer (w->buffer);
>
>> unchanged since the past release.
>
> My guess is that the switch from Fdisplay_buffer to the Elisp version of
> code, causes the windows to be created slightly differently, and this in
> turn causes delete-windows-on in this particular case to cycle through
> the windows in a different order.
> In any case, the answer is that delete-windows-on should be expected to
> change the current-buffer, so if you want it to stay unchanged, you need
> save-excursion.

Thanks, Stefan.

Another solution would be to save the content of current-buffer first,
and then use set-buffer or with-current-buffer to access it. Are one
or the other of these two functions preferred?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD





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

end of thread, other threads:[~2009-07-31 20:17 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-30 22:13 23.1: Is delete-windows-on supposed to change the current buffer? Jeffrey C Honig
2009-07-31  9:08 ` martin rudalics
2009-07-31 15:49   ` Jeffrey C Honig
2009-07-31 16:11     ` martin rudalics
2009-07-31 17:11   ` Bill Wohler
2009-07-31 18:56   ` Stefan Monnier
2009-07-31 20:17     ` Bill Wohler

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.