View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[David Reitter]

I received the bug report below from an Aquamacs user.

A little investigation traced this to the setting of `display-buffer- 
reuse-frames', which, when t, causes "View-quit" to do the wrong  
thing when restoring the previous window configuration.
In this case, the second window in the frame gets deleted, but the  
first window switches to a different buffer.

The following should reproduce it in a 22 branch CVS Emacs (with  
unrelated patches - I tried Aquamacs with -Q) and also in a 23 one (I  
tried Adrian Robert's Cocoa port):

(progn
   (setq display-buffer-reuse-frames t)
   (describe-mode)
   (other-window 1)
   (View-quit)
)



Begin forwarded message:

> From: Paul Curry <dashteacup@insightbb.com>
> Date: 10 October 2007 05:25:58 BDT
> To: aquamacs-bugs@aquamacs.org
> Subject: [Aquamacs-bugs] View-quit in *Help* restores wrong window
>
> Enter your bug report here.
>
> When I quit from a *Help* buffer (key q, command View-quit) in  
> Aquamacs
> I do not get the correct (or at least expected) behavior.  In other
> Emacsen, if you have two buffers open in a frame -- one of which is a
> *Help* buffer -- and you quit the help buffer, then the frame will  
> fill
> out to only include the other visible buffer.  In Aquamacs, however,
> View-quit fills the frame with a seemingly random unrelated buffer.
>
> For testing purposes I tried the following sequence of commands in
> both Aquamacs and Carbon Emacs:
> Start Emacs
> describe-mode
> other-window
> View-quit
> ---
> In Carbon Emacs I return to the *scratch* buffer, as expected; in
> Aquamacs I change to the *Messages* buffer.  This is reproducible
> every time.
>
> Curious, I checked out the source code for View-quit in both Emacsen
> -- they were the same.  view-mode-exit (called from View-quit) was
> also the same.  The only difference that I can notice is the value of
> view-return-to-alist.  In Carbon Emacs it is:
> ((#<window 8 on *Help*> #<window 3 on *scratch*> . t))
> and in Aqumacs it's:
> ((#<window 7 on *Help*> #<window 3 on *scratch*> . quit-window))
>
> My configuration is:
> Aquamacs 1.2
> OS X 10.4
> not using one-buffer-one-frame-mode
> opening the *Help* buffer in the current frame
>      (http://www.emacswiki.org/cgi-bin/wiki/AquamacsFAQ#toc17)
> hundreds of lines of elisp configuration
>      (I hope this isn't the problem)
>
> In GNU Emacs 22.1.50.1 (i386-apple-darwin8.10.1, Carbon Version 1.6.0)
>   of 2007-10-01 on plume.sr.unh.edu - Aquamacs Distribution 1.2a
> Windowing system distributor `Apple Inc.', version 10.4.10
> configured using `configure  '--without-x' '--prefix=/usr/local''
>
> Important settings:
>    value of $LC_ALL: nil
>    value of $LC_COLLATE: nil
>    value of $LC_CTYPE: nil
>    value of $LC_MESSAGES: nil
>    value of $LC_MONETARY: nil
>    value of $LC_NUMERIC: nil
>    value of $LC_TIME: nil
>    value of $LANG: nil
>    locale-coding-system: iso-8859-1
>    default-enable-multibyte-characters: t
>
> Major mode: Text
>
> Minor modes in effect:
>    flyspell-mode: t
>    auto-insert-mode: t
>    smart-frame-positioning-mode: t
>    aquamacs-styles-mode: t
>    recentf-mode: t
>    encoded-kbd-mode: t
>    show-paren-mode: t
>    delete-selection-mode: t
>    pc-selection-mode: t
>    cua-mode: t
>    auto-image-file-mode: t
>    tooltip-mode: t
>    mac-input-method-mode: t
>    mouse-wheel-mode: t
>    menu-bar-mode: t
>    file-name-shadow-mode: t
>    global-font-lock-mode: t
>    font-lock-mode: t
>    blink-cursor-mode: t
>    unify-8859-on-encoding-mode: t
>    utf-translate-cjk-mode: t
>    auto-compression-mode: t
>    column-number-mode: t
>    line-number-mode: t
>    transient-mark-mode: t
>
> Recent input:
> <down-mouse-1> <mouse-1> C-x C-g <menu-bar> <help-menu>
> <report-emacs-bug> C-x C-f <return> C-n C-n C-n C-n
> C-n C-n C-n C-n C-n C-n C-n C-n C-p C-p <return> M-b
> M-b M-< M-< M-< M-< M-> M-> M-< M-x C-g M-x M-g <menu-bar>
> <help-menu> <report-emacs-bug> C-g C-g <menu-bar> <help-menu>
> <report-emacs-bug>
>
> Recent messages:
> Public License, version 3 or later. Copyright (C) 2007 Free Software
> Foundation,
> Inc. (C) 2007 D. Reitter. No Warranty.
> Loading emacsbug...done
> Sending...
> Loading mailclient...done
> Loading browse-url...done
> Sending...done
> Loading dired...done
> Mark set [7 times]
> Quit [3 times]
>

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

 > A little investigation traced this to the setting of `display-buffer-
 > reuse-frames', which, when t, causes "View-quit" to do the wrong  thing
 > when restoring the previous window configuration.
 > In this case, the second window in the frame gets deleted, but the
 > first window switches to a different buffer.
 >
 > The following should reproduce it in a 22 branch CVS Emacs (with
 > unrelated patches - I tried Aquamacs with -Q) and also in a 23 one (I
 > tried Adrian Robert's Cocoa port):
 >
 > (progn
 >   (setq display-buffer-reuse-frames t)
 >   (describe-mode)
 >   (other-window 1)
 >   (View-quit)
 > )

Thanks for reporting.  This is one of a couple of known problems with
`View-quit'.  I posted a tentative patch here

http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-09/msg00154.html

and would be very glad if someone could try whether it helps to solve
this and related problems.

 > Begin forwarded message:
 >
 >> From: Paul Curry <dashteacup@insightbb.com>
 >> Date: 10 October 2007 05:25:58 BDT
 >> To: aquamacs-bugs@aquamacs.org
 >> Subject: [Aquamacs-bugs] View-quit in *Help* restores wrong window
 >>
 >> Enter your bug report here.
 >>
 >> When I quit from a *Help* buffer (key q, command View-quit) in  Aquamacs
 >> I do not get the correct (or at least expected) behavior.  In other
 >> Emacsen, if you have two buffers open in a frame -- one of which is a
 >> *Help* buffer -- and you quit the help buffer, then the frame will  fill
 >> out to only include the other visible buffer.  In Aquamacs, however,
 >> View-quit fills the frame with a seemingly random unrelated buffer.
 >>

Please try the patch cited above.  If you have any problems applying it
tell me immediately.  It would be really important if someone helped me
testing this.

 >> For testing purposes I tried the following sequence of commands in
 >> both Aquamacs and Carbon Emacs:
 >> Start Emacs
 >> describe-mode
 >> other-window
 >> View-quit
 >> ---
 >> In Carbon Emacs I return to the *scratch* buffer, as expected; in
 >> Aquamacs I change to the *Messages* buffer.  This is reproducible
 >> every time.
 >>
 >> Curious, I checked out the source code for View-quit in both Emacsen
 >> -- they were the same.  view-mode-exit (called from View-quit) was
 >> also the same.  The only difference that I can notice is the value of
 >> view-return-to-alist.  In Carbon Emacs it is:
 >> ((#<window 8 on *Help*> #<window 3 on *scratch*> . t))
 >> and in Aqumacs it's:
 >> ((#<window 7 on *Help*> #<window 3 on *scratch*> . quit-window))

Note that `view-mode-exit' just executes something that has been put on
`view-return-to-alist' (maybe a long time) before.  The source of all
problems is how the entry for `view-return-to-alist' is indirectly set
up when creating the "help window" in the first place.

I'm not sure what's causing the difference here.  To find out you could
try to edebug `print-help-return-message' on both systems and look how
the value for `help-return-method' gets assigned.  Maybe some option has
different initial values on your systems.

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[Glenn Morris]

martin rudalics wrote:

> Thanks for reporting.  This is one of a couple of known problems with
> `View-quit'.  I posted a tentative patch here
>
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-09/msg00154.html
>
> and would be very glad if someone could try whether it helps to solve
> this and related problems.

I tried your patch. It fixes this problem and the problem in the
thread where you originally posted it. Is there anything else I should
test?

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

 > I tried your patch. It fixes this problem and the problem in the
 > thread where you originally posted it. Is there anything else I should
 > test?

Thanks for testing.  So far I identified four groups of users:

(1) The one window one frame minimalist has `pop-up-frames' and
     `pop-up-windows' both and would like exiting view-mode to restore
     the window shown before.

(2) The one window per frame type has `pop-up-frames' non-nil and
     `pop-up-windows' nil and expects view-mode to pop up a new or reuse
     an existing frame.

(3) The at most two windows per frame user has `pop-up-windows' non-nil
     and `split-height-threshold' the default.  Such users expect
     view-mode to reuse any "other window" on the present frame
     regardless of its mode.

(4) The many windows per frame user has `pop-up-windows' non-nil and
     customized `split-height-threshold' appropriately.  Users in this
     group expect view-mode to reuse an existing window on the same frame
     iff it's a view-mode window.

My changes should set up information for exiting view mode correctly for
all of them.  The message printed when entering view-mode should be
correct with respect to how to scroll the help window and how to get rid
of its contents.  I have tried to test these but might have failed to
specify usage patterns correctly.  Maybe there's also another group of
users I failed to identify so far.

In addition my changes should cope with the following:

- Exiting view-mode should ideally (1) kill a window that has been
   popped up for view-mode purposes and (2) show the earlier contents of
   the window when it has been usurpated by view-mode.

- Exit information should not get overwritten when following links,
   hitting backward/forward buttons and the like (including Nick's
   `help-xref-go-forward').

- Something reasonable should be done when a user manually switches to a
   view-mode buffer and types `q' in that buffer.  Hard to get right for
   a type (2) user who intermittently displays some unrelated buffer in a
   view-mode window, manually switches back to the view-mode buffer, and
   types `q'.  What should I do here?  Kill the frame, display the other
   buffer and possibly lower the frame, iconify the frame, `bury-buffer',
   `quit-window', ...

- Is the `help-window-select' option useful?  The OP of the present
   thread had the usage pattern

   (progn
     (setq display-buffer-reuse-frames t)
     (describe-mode)
     (other-window 1)
     (View-quit)
   )

   With `help-window-select' non-nil, the `other-window' is not needed.

Getting some feedback in these areas would be very helpful.  Also, I'd
eventually want to get rid of all `print-help-return-message' instances
in the Elisp base including vhdl and python mode.  I have to check these
case by case though.  If I can get these right I'd finally like quitting
*info* and other temporary windows do something similar.

RE: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[Drew Adams]

> So far I identified four groups of users:

FWIW and IIUC, I am not in any of those 4 user groups, with any of the
expectations you assign to those groups - and I believe that I filed one of
the bugs you have been working on.

I use non-nil `pop-up-frames', and both `pop-up-windows' and
`split-height-threshold' have the default values (t and 500). I have a
dedicated *Help* frame.

Because of `pop-up-frames', `display-buffer' uses another frame, but I do
sometimes switch to a different buffer in the same window. And I do
sometimes split a window, so my frames are not always `one-window-p'.

If a new window or frame was popped up to display a view-mode buffer, then I
expect quitting to delete the window and, if one-window-p, delete the frame
too.

FWIW, my own code takes care of the latter part, so it is enough for me if
the view-mode code simply does `quit-window'.

If a new window or frame was not popped up to display the view-mode buffer,
that is, if I manually switched to it in an existing window, then I want
quitting that buffer/mode to restore the previous buffer that was in that
window.

Summary:
    if pop-up, then quit => delete the window/frame
if not pop-up, then quit => restore previous buffer for window

> - Exiting view-mode should ideally (1) kill a window that
>   has been popped up for view-mode purposes and (2) show
>   the earlier contents of the window when it has been
>   usurpated by view-mode.

That would be good. In my case, #1 is what I expect for the *Help* buffer. I
have no problem with #2, assuming that it applies to buffers that were not
popped up in another window.

I haven't followed the current thread closely. If you have a Lisp-only patch
I can try, I will do that.

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[Glenn Morris]

martin rudalics wrote:

> (1) The one window one frame minimalist has `pop-up-frames' and
>     `pop-up-windows' both and would like exiting view-mode to restore
>     the window shown before.

Seems to work fine (I assume there's a missing "nil" here).

> (2) The one window per frame type has `pop-up-frames' non-nil and
>     `pop-up-windows' nil and expects view-mode to pop up a new or reuse
>     an existing frame.

Quitting view mode iconifies the frame, which seems odd to me. This issue?

http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00103.html

> (3) The at most two windows per frame user has `pop-up-windows' non-nil
>     and `split-height-threshold' the default.  Such users expect
>     view-mode to reuse any "other window" on the present frame
>     regardless of its mode.

Seems to work fine.

> (4) The many windows per frame user has `pop-up-windows' non-nil and
>     customized `split-height-threshold' appropriately.  Users in this
>     group expect view-mode to reuse an existing window on the same frame
>     iff it's a view-mode window.

Seems to work fine.

> My changes should set up information for exiting view mode correctly for
> all of them.  The message printed when entering view-mode should be
> correct with respect to how to scroll the help window and how to get rid
> of its contents.

Yes, AFAICS.

> - Exiting view-mode should ideally (1) kill a window that has been
>   popped up for view-mode purposes and (2) show the earlier contents of
>   the window when it has been usurpated by view-mode.

Yes, AFAICS.

> - Exit information should not get overwritten when following links,
>   hitting backward/forward buttons and the like (including Nick's
>   `help-xref-go-forward').

Not sure what you mean. If you mean the "type foo to quit" message, it
seems to disappear on scrolling, clicking a link, indeed any key
press. That doesn't seem like a big problem to me though.

> - Something reasonable should be done when a user manually switches to a
>   view-mode buffer and types `q' in that buffer.  Hard to get right for
>   a type (2) user who intermittently displays some unrelated buffer in a
>   view-mode window, manually switches back to the view-mode buffer, and
>   types `q'.  What should I do here?  Kill the frame, display the other
>   buffer and possibly lower the frame, iconify the frame, `bury-buffer',
>   `quit-window', ...

Probably not too important. I would guess either kill the frame, or
display the other buffer, but it's not my use pattern.

> - Is the `help-window-select' option useful?

Looks like it could be.

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

 > FWIW and IIUC, I am not in any of those 4 user groups, with any of the
 > expectations you assign to those groups - and I believe that I filed one of
 > the bugs you have been working on.
 >
 > I use non-nil `pop-up-frames', and both `pop-up-windows' and
 > `split-height-threshold' have the default values (t and 500).

OK.  The second group gets `pop-up-frames' non-nil, the values of
`pop-up-windows' and `split-height-threshold' are of no concern.

 > I have a
 > dedicated *Help* frame.

What is the semantics of a "dedicated frame"?

 > Because of `pop-up-frames', `display-buffer' uses another frame, but I do
 > sometimes switch to a different buffer in the same window. And I do
 > sometimes split a window, so my frames are not always `one-window-p'.

If you "dedicate" a frame to the Help buffer why do you want to switch
to a different buffer in that frame?  Why do you want to split that
frame's window?

 > If a new window or frame was popped up to display a view-mode buffer, then I
 > expect quitting to delete the window and, if one-window-p, delete the frame
 > too.

I already explained that by default Help buffers are not dedicated thus
`quit-window' won't necessarily delete the associated frame.  If people
want that we can change the behavior of view-mode but that would affect
all clients of view-mode.  Alternatively we could make help-windows
dedicated (if that helps).

Currently `view-remove-frame-by-deleting' has to be set to get the
effect you want.  We could make that non-nil by default.

 > FWIW, my own code takes care of the latter part, so it is enough for me if
 > the view-mode code simply does `quit-window'.
 >
 > If a new window or frame was not popped up to display the view-mode buffer,
 > that is, if I manually switched to it in an existing window, then I want
 > quitting that buffer/mode to restore the previous buffer that was in that
 > window.
 > Summary:
 >     if pop-up, then quit => delete the window/frame
 > if not pop-up, then quit => restore previous buffer for window

Suppose you (1) pop up a view-mode window, (2) display a non view-mode
buffer in that window, (3) display a view-mode buffer in that window,
and (4) quit view-mode.  Whatever `view-mode-exit' does now, you'll
complain.

 >>- Exiting view-mode should ideally (1) kill a window that
 >>  has been popped up for view-mode purposes and (2) show
 >>  the earlier contents of the window when it has been
 >>  usurpated by view-mode.
 >
 >
 > That would be good. In my case, #1 is what I expect for the *Help* buffer. I
 > have no problem with #2, assuming that it applies to buffers that were not
 > popped up in another window.

I wrote "ideally" and I had your usage pattern in mind.  But keep in
mind that killing a window doesn't necessarily imply killing its frame.

 > I haven't followed the current thread closely. If you have a Lisp-only patch
 > I can try, I will do that.

It's still the patch I sent you earlier.

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

 >>(1) The one window one frame minimalist has `pop-up-frames' and
 >>    `pop-up-windows' both and would like exiting view-mode to restore
 >>    the window shown before.
 >
 >
 > Seems to work fine (I assume there's a missing "nil" here).

Your assumption is correct (and I enjoyed reading it).

 >>(2) The one window per frame type has `pop-up-frames' non-nil and
 >>    `pop-up-windows' nil and expects view-mode to pop up a new or reuse
 >>    an existing frame.
 >
 >
 > Quitting view mode iconifies the frame, which seems odd to me. This issue?
 >
 > http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00103.html

Yes.  Customizing `view-remove-frame-by-deleting' should cut that.  But
apparently most people don't know about that option (FWIW it's been in
view-mode ever since).

 >>- Exit information should not get overwritten when following links,
 >>  hitting backward/forward buttons and the like (including Nick's
 >>  `help-xref-go-forward').
 >
 >
 > Not sure what you mean. If you mean the "type foo to quit" message, it
 > seems to disappear on scrolling, clicking a link, indeed any key
 > press. That doesn't seem like a big problem to me though.

Badly formulated: I meant that the information view-mode maintains (in
`view-return-to-alist') in order to correctly exit a help window must
not get overwritten when the user clicks on a link or a button.  With
other words I have to make sure that quitting help doesn't get me to an
earlier (in history) help window.

 >>- Something reasonable should be done when a user manually switches to a
 >>  view-mode buffer and types `q' in that buffer.  Hard to get right for
 >>  a type (2) user who intermittently displays some unrelated buffer in a
 >>  view-mode window, manually switches back to the view-mode buffer, and
 >>  types `q'.  What should I do here?  Kill the frame, display the other
 >>  buffer and possibly lower the frame, iconify the frame, `bury-buffer',
 >>  `quit-window', ...
 >
 >
 > Probably not too important. I would guess either kill the frame, or
 > display the other buffer, but it's not my use pattern.

Drew would probably disagree here.

RE: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[Drew Adams]

>  > I have a dedicated *Help* frame.
>
> What is the semantics of a "dedicated frame"?

I should have said "special-display".

(add-to-list
 'special-display-buffer-names
 (list "*Help*" 'my-display-*Help*-frame...))

>  > Because of `pop-up-frames', `display-buffer' uses another
>  > frame, but I do sometimes switch to a different buffer in
>  > the same window. And I do sometimes split a window, so my
>  > frames are not always `one-window-p'.
>
> If you "dedicate" a frame to the Help buffer why do you want to switch
> to a different buffer in that frame?  Why do you want to split that
> frame's window?

I don't; I never said I did. I was describing my overall use, including my
use of `pop-up-frames', not my use of *Help*. You expressed some assumptions
about users with non-nil `pop-up-frames' and their never reusing a window
and never splitting a window. I was explaining that although I have
`pop-up-frames' non-nil, I still sometimes reuse or split some windows (not
*Help*, but others).

>  > If a new window or frame was popped up to display a view-mode
>  > buffer, then I expect quitting to delete the window and, if
>  > one-window-p, delete the frame too.
>
> I already explained that by default Help buffers are not dedicated thus
> `quit-window' won't necessarily delete the associated frame.

And I explained that I don't personally need you to delete the frame - I do
that myself. Deleting the window is sufficient (for *Help* or any other
buffer).

> If people want that we can change the behavior of view-mode
> but that would affect all clients of view-mode.  Alternatively
> we could make help-windows dedicated (if that helps).
>
> Currently `view-remove-frame-by-deleting' has to be set to get the
> effect you want.  We could make that non-nil by default.

I don't know or care what the default value is.
FWIW, I have that set to `t'.

>  > FWIW, my own code takes care of the latter part, so it is
>  > enough for me if the view-mode code simply does `quit-window'.
>  >
>  > If a new window or frame was not popped up to display the
>  > view-mode buffer, that is, if I manually switched to it in
>  > an existing window, then I want quitting that buffer/mode
>  > to restore the previous buffer that was in that window.
>  >
>  > Summary:
>  >     if pop-up, then quit => delete the window/frame
>  > if not pop-up, then quit => restore previous buffer for window
>
> Suppose you (1) pop up a view-mode window, (2) display a non view-mode
> buffer in that window, (3) display a view-mode buffer in that window,
> and (4) quit view-mode.  Whatever `view-mode-exit' does now, you'll
> complain.

No I won't. In that case, you can show again the non-view-mode buffer that
inhabited the window before the view-mode buffer that was quit.

If there was a buffer in the window before the view-mode buffer is placed in
it, then it's OK to show that buffer after quitting the view-mode buffer. If
there was no other buffer in the window before the view-mode buffer, then
there is no reason to display any buffer at all there - just delete the
window. And if the view-mode buffer is `one-window-p', then delete the frame
also.

>  >>- Exiting view-mode should ideally (1) kill a window that
>  >>  has been popped up for view-mode purposes and (2) show
>  >>  the earlier contents of the window when it has been
>  >>  usurpated by view-mode.
>  >
>  > That would be good. In my case, #1 is what I expect for the
>  > *Help* buffer. I have no problem with #2, assuming that it
>  > applies to buffers that were not popped up in another window.
>
> I wrote "ideally" and I had your usage pattern in mind.  But keep in
> mind that killing a window doesn't necessarily imply killing its frame.

I understand. Don't worry about the frame-killing part, at least for me. My
own code does that.

I personally think that the test of `one-window-p' should be sufficient for
deciding whether `delete-window' should also delete the frame, but I think
that some others might disagree with that. For my own needs, it is enough
that Emacs delete the window - my own code will then DTRT (for me) wrt the
frame.

>  > I haven't followed the current thread closely. If you have a
>  > Lisp-only patch I can try, I will do that.
>
> It's still the patch I sent you earlier.

Then I already provided my feedback, IIRC.

Thanks for working on this, BTW. I realize that it is not so easy to juggle
the many possibilities, including different use patterns.

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[Glenn Morris]

martin rudalics wrote:

>> Quitting view mode iconifies the frame, which seems odd to me. This issue?
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00103.html
>
> Yes.  Customizing `view-remove-frame-by-deleting' should cut that.  But
> apparently most people don't know about that option (FWIW it's been in
> view-mode ever since).

OK. I think the OP in that thread wants a third behaviour, namely just
killing/burying the help buffer, and leaving the frame alone.

His second point (an "unquittable" help buffer) remains true after
applying your patches.

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

 >>>Quitting view mode iconifies the frame, which seems odd to me. This issue?
 >>>
 >>>http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00103.html
 >>
 >>Yes.  Customizing `view-remove-frame-by-deleting' should cut that.  But
 >>apparently most people don't know about that option (FWIW it's been in
 >>view-mode ever since).
 >
 >
 > OK. I think the OP in that thread wants a third behaviour, namely just
 > killing/burying the help buffer, and leaving the frame alone.
 >
 > His second point (an "unquittable" help buffer) remains true after
 > applying your patches.

If, with Emacs -Q, I do

(setq view-remove-frame-by-deleting t)
(setq pop-up-frames t)

pop up a Help buffer and type `q' the frame gets deleted.  What else
should I do?

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

 >>What is the semantics of a "dedicated frame"?
 >
 >
 > I should have said "special-display".
 >
 > (add-to-list
 >  'special-display-buffer-names
 >  (list "*Help*" 'my-display-*Help*-frame...))

I did understand you the first time.  The Elisp manual tells me:

      By default, special display means to give the buffer a dedicated
      frame.

No special semantics for "quitting" or "deleting" dedicated frames are
given.  There's a short remark in the Emacs manual

      "Killing the special buffer deletes its frame automatically."

but I'm not sure whether you want to kill the Help buffer and I don't
know what to do when you manually switched to another buffer in that
frame in between.

 >>If you "dedicate" a frame to the Help buffer why do you want to switch
 >>to a different buffer in that frame?  Why do you want to split that
 >>frame's window?
 >
 >
 > I don't; I never said I did. I was describing my overall use, including my
 > use of `pop-up-frames', not my use of *Help*. You expressed some assumptions
 > about users with non-nil `pop-up-frames' and their never reusing a window
 > and never splitting a window. I was explaining that although I have
 > `pop-up-frames' non-nil, I still sometimes reuse or split some windows (not
 > *Help*, but others).
 >

If you do not "reuse" Help windows I don't understand why the proposed
patch doesn't work for you.  You would have to give me a recipe to
reproduce the incorrect behavior.  Problems may arise if and only if a
Help window was reused to display another buffer.

 >>I already explained that by default Help buffers are not dedicated thus
 >>`quit-window' won't necessarily delete the associated frame.
 >
 >
 > And I explained that I don't personally need you to delete the frame - I do
 > that myself. Deleting the window is sufficient (for *Help* or any other
 > buffer).

Your personal modifications won't be of any help to other Emacs users.
Let's make this generally usable.

 > If there was a buffer in the window before the view-mode buffer is placed in
 > it, then it's OK to show that buffer after quitting the view-mode buffer. If
 > there was no other buffer in the window before the view-mode buffer, then
 > there is no reason to display any buffer at all there - just delete the
 > window.

I already explained that tracking the appearance of buffers in a window
is non-trivial and has to be done in `window-configuration-change-hook'.
So far the decision about how to quit view-mode must be established when
_entering_ view-mode.

 > And if the view-mode buffer is `one-window-p', then delete the frame
 > also.

If people agree that typing `q' should be allowed to unequivocally
delete a frame.

RE: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[Drew Adams]

>  > I should have said "special-display".
>  > (add-to-list
>  >  'special-display-buffer-names
>  >  (list "*Help*" 'my-display-*Help*-frame...))
>
> I did understand you the first time.  The Elisp manual tells me:
>
>       By default, special display means to give the buffer a dedicated
>       frame.
>
> No special semantics for "quitting" or "deleting" dedicated frames are
> given.  There's a short remark in the Emacs manual
>
>       "Killing the special buffer deletes its frame automatically."
>
> but I'm not sure whether you want to kill the Help buffer and I don't
> know what to do when you manually switched to another buffer in that
> frame in between.

As I said, I do *not* switch to another buffer in the same window as *Help*
(which is dedicated). I don't think that's even possible, but I could be
mistaken.

As far as I am concerned, quitting *Help* can delete the buffer or the
window. Either way, my own code will then delete the frame. For me, at
least, quitting *Help* should never just do nothing (which it does
sometimes), and it should never iconify the frame (which it does sometimes).
All that's needed for my own use case is for `q' to call `quit-window', as
I've said before. I can't speak for others, who might have different needs.

>  >>If you "dedicate" a frame to the Help buffer why do you want to switch
>  >>to a different buffer in that frame?  Why do you want to split that
>  >>frame's window?
>  >
>  > I don't; I never said I did. I was describing my overall use,
>  > including my use of `pop-up-frames', not my use of *Help*.
>  > You expressed some assumptions about users with non-nil
>  > `pop-up-frames' and their never reusing a window
>  > and never splitting a window. I was explaining that although I have
>  > `pop-up-frames' non-nil, I still sometimes reuse or split some
>  > windows (not *Help*, but others).
>
> If you do not "reuse" Help windows I don't understand why the proposed
> patch doesn't work for you.  You would have to give me a recipe to
> reproduce the incorrect behavior.  Problems may arise if and only if a
> Help window was reused to display another buffer.

I don't recall how well your patch worked for me. I tried it and reported
what I saw to you quite a while ago. I don't even have the patch anymore.

I sent my recent message in reply to yours, which summarized the possible
use cases. I mentioned that, FWIW, my own preferred *Help* behavior was not
represented in your summary, and I indicated the *Help* quitting behavior
that I would like to see. If your patch satisfies that, then there is no
problem. If, however, the *Help* window is not deleted (`q' does nothing) or
the *Help* frame is iconified, then it still does not provide the behavior I
need. And so on, wrt non-dedicated buffers and what I said about them in my
last mail (quoted below).

>  >>I already explained that by default Help buffers are not dedicated thus
>  >>`quit-window' won't necessarily delete the associated frame.
>  >
>  > And I explained that I don't personally need you to delete the
>  > frame - I do that myself. Deleting the window is sufficient
>  > (for *Help* or any other buffer).
>
> Your personal modifications won't be of any help to other Emacs users.
> Let's make this generally usable.

I proposed for vanilla Emacs that `delete-window' delete also the frame if
the window is alone there (`one-window-p). I think that would be "generally
usable". But some people with different use cases disagreed. I also proposed
that an option be available to at least let users choose that behavior. That
too was rejected.

So anyone who wants the delete-sole-window-also-deletes-frame behavior will
need to either use my code or roll his/her own. (FWIW, my code is here:
http://www.emacswiki.org/cgi-bin/wiki/OneOnOneEmacs.)

If you would simply delete the *Help* window upon quitting, then I would be
happy wrt *Help*, and no one else would be required to share my desire for
the frame also to be deleted.

Again, (1) `q' = `quit-window' suffices for me, and probably for some others
in your use-case list. Alternatively (for me), (2) deleting the *Help*
window or (3) the *Help* buffer is sufficient. Any of those 3 approaches
works for me.

>  > If there was a buffer in the window before the view-mode
>  > buffer is placed in it, then it's OK to show that buffer
>  > after quitting the view-mode buffer. If there was no other
>  > buffer in the window before the view-mode buffer, then
>  > there is no reason to display any buffer at all there -
>  > just delete the window.
>
> I already explained that tracking the appearance of buffers in a window
> is non-trivial and has to be done in `window-configuration-change-hook'.
> So far the decision about how to quit view-mode must be established when
> _entering_ view-mode.

You asked me to describe the behavior I prefer, so I did. I think that what
I wrote (and you just quoted) makes sense; it is reasonable behavior to
expect: When you quit view-mode, if there was another non-view-mode buffer
in the window prior to the viewed buffer, then return to it; otherwise,
delete the window.

More exactly, return to the most recent non view-mode buffer previously in
the same window, if any; if none, then delete the window. I doubt that
anyone wants to return to a view-mode buffer, but I might be mistaken. Even
that would be OK: if there was any buffer at all in the window before the
view-mode buffer, then return to it; if not, then delete the view-mode
window when quitting view mode.

What is definitely not useful is to put some other buffer in the window,
which was never shown in that window before. When a view-mode window pops up
(new frame), quitting the mode should not stick some unrelated buffer in
that window. In this use case, think of a window such as *Help* as a
(non-modal) dialog box. When you quit that dialog box, you don't want its
window to remain, filled with some extraneous buffer that you happened to
access half an hour ago or 3 days ago. That just doesn't make sense.

Anyway, those are the behaviors I see as reasonable and unreasonable. I
cannot speak to the difficulty of implementation. I can say, however, that
Emacs 20 has no such problems.

I'm no expert on this, but my impression is that the view-mode code (or
perhaps it is the help-mode code) is trying to be too smart these days, and
it fails to be smart enough. It was better, IMO, when it was simple,
reliable, and stupid. Users then knew what to expect; the behavior was
predictable and reasonable. Emacs 22.1 sometimes does nothing for `q' in
*Help*, sometimes deletes the window, and sometimes iconifies the frame -
there is a UI problem. (I'm not speaking about your patch; I'm speaking
about Emacs 22.1.)

>  > And if the view-mode buffer is `one-window-p', then delete the frame
>  > also.
>
> If people agree that typing `q' should be allowed to unequivocally
> delete a frame.

Again, if people don't agree about deleting the frame (and I'm sure that
some do not agree), there is still no problem. Those who want that behavior
can use my code or roll their own. It would be preferable, however, that
they have the possibility of choosing that behavior within vanilla Emacs
(e.g. via an option).

I admit that I don't fathom the view-mode and help-mode code. I can only
speak as a user here. Maybe help mode should not use view mode, but should
deal with quitting itself; I don't know. I do know that things are not quite
right yet (in Emacs 22.1).

Again, I sincerely thank you for trying to make sense of this and improve
the code. I know it's not easy to satisfy everyone. I hope it's clear at
least, what I would like to see, if possible.

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[Glenn Morris]

martin rudalics wrote:

>>>>http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg00103.html
[...]
> If, with Emacs -Q, I do
>
> (setq view-remove-frame-by-deleting t)
> (setq pop-up-frames t)
>
> pop up a Help buffer and type `q' the frame gets deleted.  What else
> should I do?

In case there's any confusion, I'm agreeing that your patch seems like
a definite improvement and handles all the cases you listed. But FWIW,
it does not seem to improve the behaviour described in the URL quoted
above (multiple frames created by hand, with pop-up-frames non-nil,
which seems a reasonable thing to do).

To be precise:

emacs -Q -f make-frame
C-h f find-file
C-x 0
q

-> frame gets iconified (or deleted if view-remove-frame-by-deleting
is non-nil). Burying the help buffer and leaving the frame alone
(since it was created manually) would seem like the Right Thing here.

The second problem can basically be summarized as quit only working
once. Eg:

emacs -Q
C-h find-file
C-x 1
C-x b *Help*
q

-> "q" has no effect at all

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

 > As I said, I do *not* switch to another buffer in the same window as *Help*
 > (which is dedicated). I don't think that's even possible, but I could be
 > mistaken.

It's possible.

 > What is definitely not useful is to put some other buffer in the window,
 > which was never shown in that window before. When a view-mode window pops up
 > (new frame), quitting the mode should not stick some unrelated buffer in
 > that window. In this use case, think of a window such as *Help* as a
 > (non-modal) dialog box. When you quit that dialog box, you don't want its
 > window to remain, filled with some extraneous buffer that you happened to
 > access half an hour ago or 3 days ago. That just doesn't make sense.

I fully agree with you.  But `quit-window' does exactly that when the
window is not dedicated:

	  (switch-to-buffer (other-buffer))))

This is the painful default behavior of `Info-exit' when you do not use
a separate frame (try with Emacs -Q, split the *scratch* window, invoke
Info, and quit - you won't get the "previously selected buffer" as
promised by the doc-string of `Info-mode').

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

 > emacs -Q -f make-frame
 > C-h f find-file
 > C-x 0
 > q
 >
 > -> frame gets iconified (or deleted if view-remove-frame-by-deleting
 > is non-nil). Burying the help buffer and leaving the frame alone
 > (since it was created manually) would seem like the Right Thing here.

Yes.  I could create an additional `view-return-to-alist' element like
'delete-window-but-not-frame and not iconify/kill the frame in that
case.  Alternatively, I could, in `view-mode-exit' do

	     ((not (eq old-buf-info t)) nil)	; Not case 2, do nothing.
	     ((not (one-window-p t)) (delete-window))
	     ((not pop-up-frames) (bury-buffer)) ; <--- BURY BUFFER HERE
	     ((not (eq frame (next-frame)))
	      ;; Not the only frame, so can safely be removed.

but this would obviously fail for users with `pop-up-frames' non-nil.

Unfortunately, fiddling around with C-x 0 and C-x 1 will likely create
other cases that cannot be handled easily.  C-x 2 on a help window is
another point of concern.  Finally, I have little experience with
cloned Help buffers.

 > The second problem can basically be summarized as quit only working
 > once. Eg:
 >
 > emacs -Q
 > C-h find-file
 > C-x 1
 > C-x b *Help*
 > q
 >
 > -> "q" has no effect at all

I cannot reproduce this, my Emacs has "q" display *scratch* instead.
This is set up in help-mode's

(defun help-mode ()
   ...
   (setq view-exit-action
	(lambda (buffer)
	  (with-current-buffer buffer
	    ;; Use `with-current-buffer' to assert that `bury-buffer'
	    ;; removes buffer from the selected window.  Leave it to
	    ;; `view-mode-exit' to delete the associated window(s).
	    (bury-buffer))))
   (run-mode-hooks 'help-mode-hook))

Can you investigate why this fails for you?

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[David Reitter]

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

On 14 Oct 2007, at 09:42, martin rudalics wrote:
>
> Thanks for reporting.  This is one of a couple of known problems with
> `View-quit'.  I posted a tentative patch here
>
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-09/msg00154.html
>
> and would be very glad if someone could try whether it helps to solve
> this and related problems.

OK, this fixes the problem. As given in the e-mail linked above, the  
patch won't apply because of word wrapping on the web server and some  
whitespace issues, but once that's fixed it worked for me with the  
current version 22 branch.

Thanks.

PS.: To the OP: you can download a version of Aquamacs that has the  
patch applied here: http://aquamacs.org/nightlies.shtml  (please  
allow 12 hours from now for the PPC build.)


[-- Attachment #2: Type: text/html, Size: 1405 bytes --]

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[Glenn Morris]

martin rudalics wrote:

>> emacs -Q
>> C-h find-file
>> C-x 1
>> C-x b *Help*
>> q
>>
>> -> "q" has no effect at all
>
> I cannot reproduce this, my Emacs has "q" display *scratch* instead.

I see the above behaviour in Emacs-22.1. After applying your patches,
it's better in that the above works correctly, but if I repeat the
`C-x b *Help*' a second time, then `q' has no effect. Do you see that?

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

 >>>emacs -Q
 >>>C-h find-file
 >>>C-x 1
 >>>C-x b *Help*
 >>>q
 >>>
 >>>-> "q" has no effect at all
 >>
 >>I cannot reproduce this, my Emacs has "q" display *scratch* instead.
 >
 >
 > I see the above behaviour in Emacs-22.1. After applying your patches,
 > it's better in that the above works correctly, but if I repeat the
 > `C-x b *Help*' a second time, then `q' has no effect. Do you see that?

Yes.  The problem is that `view-exit-action' is reset to nil after
exiting once.  This is hardly TRT when the buffer is _not_ killed.
Hence we could simplify the tail of `view-mode-exit' to

       (when exit-action
	(funcall exit-action buffer))
       (force-mode-line-update))))

Since `view-exit-action' is buffer-local I don't see any problems either
when the buffer _is_ killed.

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[David Reitter]

On 14 Oct 2007, at 09:42, martin rudalics wrote:
>
> Thanks for reporting.  This is one of a couple of known problems with
> `View-quit'.  I posted a tentative patch here
>
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-09/msg00154.html
>
> and would be very glad if someone could try whether it helps to solve
> this and related problems.


Thanks for this patch.

I've had it in my emacs and in the Aquamacs CVS whose nightly builds a  
couple of people use for a month, and I haven't seen any issues with  
respect to view-quit. I just noticed that you posted a new patch a few  
days later, but we haven't tried that.
(Some hunks of the original patch don't apply any longer.)

Is this going to make its way into 22.2?

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

> I've had it in my emacs and in the Aquamacs CVS whose nightly builds a  
> couple of people use for a month, and I haven't seen any issues with  
> respect to view-quit. I just noticed that you posted a new patch a few  
> days later, but we haven't tried that.
> (Some hunks of the original patch don't apply any longer.)
> 
> Is this going to make its way into 22.2?

It's in the trunk now with a couple of minor modifications.
I'm afraid that moving it back to 22.2 will rather break
things than fixing them.  Can you tell me which hunks don't
apply any more?

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[David Reitter]

On Nov 29, 10:22 am, martin rudalics <rudal...@gmx.at> wrote:

> It's in the trunk now with a couple of minor modifications.
> I'm afraid that moving it back to 22.2 will rather break
> things than fixing them.  Can you tell me which hunks don't
> apply any more?

Sure. I've applied it to the 22 branch, though.

patching file lisp/descr-text.el
patching file lisp/disp-table.el
patching file lisp/faces.el
Hunk #6 FAILED at 1504.
Hunk #7 FAILED at 1646.
2 out of 7 hunks FAILED -- saving rejects to file lisp/faces.el.rej
patching file lisp/help-fns.el
patching file lisp/help-mode.el
patching file lisp/help.el
Hunk #1 succeeded at 124 (offset 1 line).
Hunk #2 succeeded at 433 (offset 2 lines).
Hunk #3 succeeded at 445 (offset 2 lines).
Hunk #4 succeeded at 720 (offset 2 lines).
Hunk #5 succeeded at 756 (offset 2 lines).
Hunk #6 succeeded at 773 (offset 2 lines).
Hunk #7 succeeded at 841 (offset 2 lines).
Hunk #8 succeeded at 974 (offset 2 lines).
patching file lisp/view.el

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[martin rudalics]

> patching file lisp/faces.el
> Hunk #6 FAILED at 1504.
> Hunk #7 FAILED at 1646.
> 2 out of 7 hunks FAILED -- saving rejects to file lisp/faces.el.rej

I recall this has been changed.  I can compile a multi-file patch
that should work against emacs-base (for a while).   Are you using a
script for applying such patches to Aquamacs builds?  Is Emacs trunk
disfunctional for you, BTW?

Re: View-quit in *Help* restores wrong window when display-buffer-reuse-frames is t

[David Reitter]

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

On 1 Dec 2007, at 09:20, martin rudalics wrote:

>> patching file lisp/faces.el
>> Hunk #6 FAILED at 1504.
>> Hunk #7 FAILED at 1646.
>> 2 out of 7 hunks FAILED -- saving rejects to file lisp/faces.el.rej
>
> I recall this has been changed.  I can compile a multi-file patch
> that should work against emacs-base (for a while).

Well, I'm building 22 for now.

> Are you using a
> script for applying such patches to Aquamacs builds?  Is Emacs trunk
> disfunctional for you, BTW?


Yes, there's about 40 patches that are applied during the Aquamacs  
build process.

I haven't tried the trunk in a while (but I hear Carbon is working  
again, right?). Aquamacs is based on the 22 CVS builds, and I think  
that's the most sensible thing to do. Perhaps we'll lock it to 22.2 if  
that is reasonably bug-free.

I'm taking your view-mode patch out again now since you said that it  
might break things in 22.x. But please consider fixing the view bug in  
the 22 branch. It'll be a long time before users will benefit from  
changes to the trunk...

- D


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]