quitting help buffer

quitting help buffer

[Drew Adams]

I cannot figure out how to make `q' do what it used to do in Emacs 20, to
quit the *Help* buffer.

I use non-nil `pop-up-frames'. I want `q' to do the equivalent of
`quit-window'. In my context, that will kill the buffer and delete its frame
(thanks to my redefining `delete-window' to DTRT for one-window
pop-up-frames).  Bye; good riddance.

I don't want `q' to iconify the frame, slip it in my back pocket, mail it to
me, or do any of the other strange and wonderful things I see advertised in
the doc for `view-mode'. How can I get `q' to do something as simple as kill
the buffer and delete its window (frame)?

BTW, I find the doc string for view-mode difficult to understand wrt the
various quitting scenarios. It doesn't help that there are multiple
similarly named commands that use synonyms for "quit" as their only
distinction:

 View-quit
 View-exit
 View-exit-and-edit
 View-quit-all
 View-leave
 View-kill-and-leave

What is this? The variations don't tell us anything in particular about what
the functions do - there is no significant difference between the words
"quit", "exit", and "leave".

Why not also
View-split, -give-up, -depart, -drop-out, -relinguish, -throw-in-the-towel, 
-take-leave, -go-away, -go-out, -get-out, -pull-up-stakes, and -escape? Or
are those variants being saved for Emacs 23? Not to mention combinations of
these with possible subsequent
actions: -and-kill, -and-pass-out, -and-hang-around, -and-go-down-to-the-poo
l-hall,...

Could this be a sign that something is wrong in the design? Isn't it a bit
bizarre for a command to spend so much effort trying to deal with all of the
possible ways and contexts in which it might be called (used)? Shouldn't
such concerns be for the callers and not the callee? This seems bass
ackwards, to me.

Re: quitting help buffer

[Richard M. Stallman]

    I don't want `q' to iconify the frame, slip it in my back pocket, mail it to
    me, or do any of the other strange and wonderful things I see advertised in
    the doc for `view-mode'. How can I get `q' to do something as simple as kill
    the buffer and delete its window (frame)?

When I try it, it deletes the frame but does not kill the buffer.
Isn't that good enough?  Is it crucial for some reason to kill
the *Help* buffer?

RE: quitting help buffer

[Drew Adams]

        I don't want `q' to iconify the frame, slip it in my back
        pocket, mail it to
        me, or do any of the other strange and wonderful things I
        see advertised in
        the doc for `view-mode'. How can I get `q' to do something
        as simple as kill
        the buffer and delete its window (frame)?

    When I try it, it deletes the frame but does not kill the buffer.
    Isn't that good enough?  Is it crucial for some reason to kill
    the *Help* buffer?

No, there is no need to kill the buffer - deleting the frame is what I'm
really after, here. Sorry if I confused the two (I often end up killing the
buffer to delete the frame, because my `C-x k' does that).

But that is not the behavior I get. For me, it iconifies the frame. And, in
some (rarer) cases, it leaves the frame displayed (no change): `q' does
nothing at all in those cases.

I suppose it depends on how (in what context) the *Help* buffer was
displayed. (It could also have something to do with my platform?) I don't
have the time now, myself, to track down the different contexts.

This is part of what I meant by our trying to be too sophisticated wrt
figuring out how view-mode was entered and how to most intelligently exit
it. It's too complicated for me to follow, and, in particular, it doesn't
DTRT when pop-up-frames = t.

The latter is a general problem, which I've mentioned before: things are
worked out well enough for the case where pop-up-frames = nil, but not for
`t'. In this case, due to the myriad fancy treatments of view-mode quitting,
it's hard to fathom what to do to make it work right for pop-up-frames = t.
And then there are dedicated and non-dedicated windows to worry about...

Bottom line: I'd like `q' to delete a one-window frame (dedicated window or
not). How to do that in all of the various view-mode cases, I know not.

(More generally, I don't see why a command should worry so much about how it
was called, and try to figure out what to do next, based on the calling
context - that seems the wrong approach, to me.)

Re: quitting help buffer

[Richard M. Stallman]

    No, there is no need to kill the buffer - deleting the frame is what I'm
    really after, here. Sorry if I confused the two (I often end up killing the
    buffer to delete the frame, because my `C-x k' does that).

    But that is not the behavior I get. For me, it iconifies the frame. And, in
    some (rarer) cases, it leaves the frame displayed (no change): `q' does
    nothing at all in those cases.

It doesn't fail for me, so there's nothing I can do.

view mode: `q' does not delete frame

[Drew Adams]

See emacs-devel list messages of 9/8 and 9/9/2005, subject "quitting
help buffer". RMS's conclusion was "It doesn't fail for me, so there's
nothing I can do." By that he meant that for him `q' always deleted
the frame.

Here is a recipe to reproduce the bug. 

emacs -q

M-x set-variable RET pop-up-frames t

M-x apropos-zippy RET wash RET

Try `q' in the frame *Apropos Zippy*. It does nothing. I want it to
delete the frame.

Note: In other contexts, the frame is iconified instead of nothing
happening. I always want it to be deleted, never iconified.


In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on
 NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (3.3) --cflags
 -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include
 -I../../tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include
 -I../../zlib-1.2.2/include'

RE: view mode: `q' does not delete frame

[Drew Adams]

    See emacs-devel list messages of 9/8 and 9/9/2005, subject "quitting
    help buffer". RMS's conclusion was "It doesn't fail for me, so there's
    nothing I can do." By that he meant that for him `q' always deleted
    the frame.

    Here is a recipe to reproduce the bug.
    emacs -q
    M-x set-variable RET pop-up-frames t
    M-x apropos-zippy RET wash RET
    Try `q' in the frame *Apropos Zippy*.

    It does nothing. I want it to delete the frame.
    Note: In other contexts, the frame is iconified instead of nothing
    happening. I always want it to be deleted, never iconified.

I meant to send that to emacs-pretest, but since I sent it here, I'll
continue here with the followup.

Even without setting pop-up-frames = t, `q' does nothing in buffer *Apropos
Zippy*, which is in view-mode. Same recipe, without the `set-variable'. Use
`C-x o' to get to the buffer, then try `q'.

If you use `M-x apropos', on the other hand, using `q' in the *Apropos*
buffer gets rid of the buffer (it does `quit-window'). It doesn't get rid of
the window, but in my pop-up-frames=t case, `quit-window' does get rid of
the (dedicated-window) frame. If that behavior (get rid of the frame) could
be used always, I'd be happy.

*Apropos* is not in view-mode, however - the problem is with view-mode. In
*Apropos*, `q' does `quit-window', which is exactly what I wish it would do
in view-mode.

Re: view mode: `q' does not delete frame

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Wed, 30 Nov 2005 16:44:21 -0800
> 
> See emacs-devel list messages of 9/8 and 9/9/2005, subject "quitting
> help buffer". RMS's conclusion was "It doesn't fail for me, so there's
> nothing I can do." By that he meant that for him `q' always deleted
> the frame.

Richard, is this indeed so? does `q' on your system indeed delete the
frame that shows the *Apropos Zippy* buffer, in "emacs -Q", and
without any customizations except setting pop-up-frames?  After
reading the code (see below), I'm surprised that things could work for
you as Drew expects them to.

> emacs -q
> 
> M-x set-variable RET pop-up-frames t
> 
> M-x apropos-zippy RET wash RET
> 
> Try `q' in the frame *Apropos Zippy*. It does nothing. I want it to
> delete the frame.

I looked into this and found a small mess.

First, view-mode is only supposed to delete the frame if you set
view-remove-frame-by-deleting to a non-nil value; otherwise it
iconifies the frame.  Did you set that variable? if not, View Mode is
not supposed to do what you want.

But don't rush to set it just yet, `cause that's just the tip of an
iceberg.  The apropos and help commands don't invoke the full
view-mode as it was supposed to be, via view-mode-enter; instead, they
call view-mode directly, and arrange for what happens when you type
`q' in the function `print-help-return-message'.  That function sets
the variable help-return-method, but it doesn't support pop-up-frames,
only pop-up-windows, special-display-buffer-names and
special-display-regexps.  If I use one of the special-display-*
variables to include *Help* and *Apropos* buffers in the respective
lists, the frames that show those buffers are deleted when I press
`q'.  I'm guessing that you didn't set special-display-* variables to
include any of the buffers mentioned in this thread.

But even setting special-display-* doesn't work for `apropos-zippy',
since it fails to call `print-help-return-message', like the other
help commands do, and thus help return method is left at its default.
This is a bug in yow.el, I think.

So, unless someone finds where I'm wrong in my conclusions, I think we
should modify `print-help-return-message' to support pop-up-frames,
and add a call to `print-help-return-message' in `apropos-zippy'.  Any
objections or further insights, anyone?

Finally, I'd like to respond to your gripes (expressed in some quite
strong language, too strong if you ask me) in your original message
back in September about the names of the View-* functions that exit
the view mode in various ways.  I do agree that some of the names are
not descriptive enough, so I suggest the following changes in those
names:

  View-quit                  -> View-quit (no change)
  View-quit-all	             -> View-quit-restore-all-windows
  View-exit                  -> View-exit-view-mode
  View-exit-and-edit         -> View-edit
  View-leave                 -> View-quit-keep-current-buffer
  View-kill-and-leave        -> View-quit-kill-current-buffer

WDYT?

RE: view mode: `q' does not delete frame

[Drew Adams]

    I looked into this and found a small mess.

    First, view-mode is only supposed to delete the frame if you set
    view-remove-frame-by-deleting to a non-nil value; otherwise it
    iconifies the frame.  Did you set that variable? if not, View Mode is
    not supposed to do what you want.

Yes, that's what I ended up doing. I found that option after I filed the
report in September, though. I guess the apropos-zippy behavior is
independent of the previously reported problem.

    But don't rush to set it just yet, `cause that's just the tip of an
    iceberg.  The apropos and help commands don't invoke the full
    view-mode as it was supposed to be, via view-mode-enter; instead, they
    call view-mode directly, and arrange for what happens when you type
    `q' in the function `print-help-return-message'.  That function sets
    the variable help-return-method, but it doesn't support pop-up-frames,
    only pop-up-windows, special-display-buffer-names and
    special-display-regexps.  If I use one of the special-display-*
    variables to include *Help* and *Apropos* buffers in the respective
    lists, the frames that show those buffers are deleted when I press
    `q'.  I'm guessing that you didn't set special-display-* variables to
    include any of the buffers mentioned in this thread.

Yes, I have special-display-regexps's = ("[ ]?[*][^*]+[*]").

    But even setting special-display-* doesn't work for `apropos-zippy',
    since it fails to call `print-help-return-message', like the other
    help commands do, and thus help return method is left at its default.
    This is a bug in yow.el, I think.

I guess that's all this last gripe concerns, then: `apropos-zippy'. I was
thinking this was related to the previous report and, frankly, I had
forgotten that I had found and set view-remove-frame-by-deleting.

I would prefer, of course, that if pop-up-frames = non-nil, the behavior of
view-remove-frame-by-deleting would follow automatically (by default). For
example, instead of having the default value be nil, have it be (not
pop-up-frames).

    So, unless someone finds where I'm wrong in my conclusions, I think we
    should modify `print-help-return-message' to support pop-up-frames,
    and add a call to `print-help-return-message' in `apropos-zippy'.  Any
    objections or further insights, anyone?

    Finally, I'd like to respond to your gripes (expressed in some quite
    strong language, too strong if you ask me) in your original message
    back in September about the names of the View-* functions that exit
    the view mode in various ways.  I do agree that some of the names are
    not descriptive enough, so I suggest the following changes in those
    names:
      View-quit                  -> View-quit (no change)
      View-quit-all	         -> View-quit-restore-all-windows
      View-exit                  -> View-exit-view-mode
      View-exit-and-edit         -> View-edit
      View-leave                 -> View-quit-keep-current-buffer
      View-kill-and-leave        -> View-quit-kill-current-buffer
    WDYT?

Sorry about the sarcasm (one person's funny is another person's annoying). I
was frustrated with view-mode, but I didn't mean to harm any humans while
venting against it.

My take on the names:

The functions are all ways of quitting view-mode, so they should all start
with View-quit (or View-exit or ...) - no mixing of synonyms (exit etc.).
None of them should be called just View-quit, as none of them seems to be
the "main" (default) way of quitting, and even if one were, people would
still wonder what it does specifically.

Judging by the doc strings, these names come to mind:

 - View-quit-keep-buffer
 - View-quit-edit-buffer
 - View-quit-kill-buffer
 - View-quit-restore-all-buffers
 - View-quit-restore-other-buffer (but it's not clear which buffer is
restored).

My main question about the names cannot be addressed for this release: Is it
really necessary to have so many ways to quit? Could this proliferation be a
sign that the design is not as it should be? Why does quitting a mode need
to be so concerned about which context to restore? Perhaps the restoration
context should be passed when the mode is entered? Or perhaps the caller
should control it some other way. And so on. It seems odd to me that a
function is so concerned with how it was called.

Thanks,

  Drew

Re: view mode: `q' does not delete frame

[Richard M. Stallman]

    Richard, is this indeed so? does `q' on your system indeed delete the
    frame that shows the *Apropos Zippy* buffer, in "emacs -Q", and
    without any customizations except setting pop-up-frames?

Alas, I don't remember anything about this any longer.
Thanks for tracking down what appears to be a bug.

Re: view mode: `q' does not delete frame

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 1 Dec 2005 17:57:16 -0800
> 
> I would prefer, of course, that if pop-up-frames = non-nil, the behavior of
> view-remove-frame-by-deleting would follow automatically (by default).

Well, I'm not sure about this: is it really true that someone who
wants view-mode to create a frame for every new buffer in view mode
would like such frame to automatically go away when they quite view
mode?  (This issue is complicated by the fact that Help commands use a
variant of view mode, so please disregard the Help commands when you
think about this question.)

Anyway, the changes I suggested will remove the frames showing Help
buffers, even if you don't have view-remove-frame-by-deleting set
non-nil.

Re: view mode: `q' does not delete frame

[Eli Zaretskii]

> Date: Thu, 01 Dec 2005 22:42:03 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> So, unless someone finds where I'm wrong in my conclusions, I think we
> should modify `print-help-return-message' to support pop-up-frames,
> and add a call to `print-help-return-message' in `apropos-zippy'.  Any
> objections or further insights, anyone?

No one objected, so I did that.

Re: view mode: `q' does not delete frame

[Stefan Monnier]

>> I would prefer, of course, that if pop-up-frames = non-nil, the behavior of
>> view-remove-frame-by-deleting would follow automatically (by default).

> Well, I'm not sure about this: is it really true that someone who
> wants view-mode to create a frame for every new buffer in view mode
> would like such frame to automatically go away when they quite view
> mode?

To "go away"?  Probably.
But "to delete"?  No.

I know Drew always wants to delete such frames because his window-manager
and use pattern make it inconvenient to have too many iconified windows.

OTOH with my window manager and my usage pattern, it's the reverse: deleting
frames is a major pain in the rear because when they are re-created, I have
to manually place them again (and set various other attributes like size,
set of workspaces they should appear in, ...).

So we should have a function to "make a frame go away" (probably bury-buffer
or quit-window or both) and use that, and then make this function
customizable so that we can decide whether to delete or to iconify.


        Stefan

RE: view mode: `q' does not delete frame

[Drew Adams]

    >> I would prefer, of course, that if pop-up-frames = non-nil,
    the behavior of
    >> view-remove-frame-by-deleting would follow automatically (by
    default).

    > Well, I'm not sure about this: is it really true that someone who
    > wants view-mode to create a frame for every new buffer in view mode
    > would like such frame to automatically go away when they quite view
    > mode?

    To "go away"?  Probably. But "to delete"?  No.

    I know Drew always wants to delete such frames because his
    window-manager and use pattern make it inconvenient to have
    too many iconified windows.

    OTOH with my window manager and my usage pattern, it's the
    reverse: deleting frames is a major pain in the rear because
    when they are re-created, I have to manually place them
    again (and set various other attributes like size,
    set of workspaces they should appear in, ...).

    So we should have a function to "make a frame go away"
    (probably bury-buffer or quit-window or both) and use that,
    and then make this function customizable so that we can
    decide whether to delete or to iconify.

I agree with Stefan. Iconifying is terrible in Windows and frame
deletion/creation is instantaneous. Other platforms can be the other way
around. And users can prefer one or the other behavior.

If frame invisibility were not bugged, I think that would be a good general
solution (i.e. good candidate for the default value). But it is bugged. For
quite a while (Emacs 19 or 20) I made frames invisible instead of iconifying
or deleting them - when bugs don't raise their ugly heads, it's an elegant
solution. Most of the time spent creating a frame (at least back then, on
Unix) was apparently spent defining it, not displaying it, so making an
invisible frame visible again was instantaneous - and it returns to the same
place it last was, with the same properties (which is Stefan's main problem
with frame deletion and re-creation, IIUC).

If others agree with Stefan and I, the next question would be the default
value for quitting. I obviously vote for frame deletion (e.g. via
quit-window), and I'm sure Stefan votes for frame iconification (e.g. via
bury-buffer). As long as this is an option, the default value is of course
not that important.

(BTW - The problem with iconification on Windows is not just the presence of
numerous unneeded icons; it's the distraction of the animated iconification:
the frame visibly streams to become an icon - it doesn't just disappear and
an icon appear.)

Thanks for looking into this. Perhaps, after the release, we can look at
fixing frame invisibility, so that could be used in cases like this. (I
don't know - perhaps it's already been looked at and deemed unfixable.)

Re: view mode: `q' does not delete frame

[Stefan Monnier]

> If frame invisibility were not bugged, I think that would be a good general
> solution (i.e. good candidate for the default value).

Could be a good default indeed.  Although having it be an option would be
even better because I much prefer iconification.

> But it is bugged.

Could you resend your bug-reports?


        Stefan

RE: view mode: `q' does not delete frame

[Drew Adams]

    > If frame invisibility were not bugged, I think that would be 
    a good general
    > solution (i.e. good candidate for the default value).
    
    Could be a good default indeed.  Although having it be an 
    option would be
    even better because I much prefer iconification.
    
    > But it is bugged.
    
    Could you resend your bug-reports?
    
Done - sent to emacs-pretest.