23.1: Is delete-windows-on supposed to change the current buffer?

23.1: Is delete-windows-on supposed to change the current buffer?

[Jeffrey C Honig]

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>

Re: 23.1: Is delete-windows-on supposed to change the current buffer?

[martin rudalics]

 > 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

Re: 23.1: Is delete-windows-on supposed to change the current buffer?

[Jeffrey C Honig]

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>

Re: 23.1: Is delete-windows-on supposed to change the current buffer?

[martin rudalics]

 > 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

Re: 23.1: Is delete-windows-on supposed to change the current buffer?

[Bill Wohler]

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

Re: 23.1: Is delete-windows-on supposed to change the current buffer?

[Stefan Monnier]

> `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

Re: 23.1: Is delete-windows-on supposed to change the current buffer?

[Bill Wohler]

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