unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: view mode: `q' does not delete frame
Date: Thu, 01 Dec 2005 22:42:03 +0200	[thread overview]
Message-ID: <uek4wczxg.fsf@gnu.org> (raw)
In-Reply-To: <DNEMKBNJBGPAOPIJOOICMEIJCPAA.drew.adams@oracle.com>

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

  parent reply	other threads:[~2005-12-01 20:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-09  3:56 quitting help buffer Drew Adams
2005-09-09 12:50 ` Richard M. Stallman
2005-09-09 16:05   ` Drew Adams
2005-09-10  8:14     ` Richard M. Stallman
2005-12-01  0:44       ` view mode: `q' does not delete frame Drew Adams
2005-12-01  1:16         ` Drew Adams
2005-12-01 20:42         ` Eli Zaretskii [this message]
2005-12-02  1:57           ` Drew Adams
2005-12-03  9:55             ` Eli Zaretskii
2005-12-03 15:08               ` Stefan Monnier
2005-12-03 15:37                 ` Drew Adams
2005-12-03 21:35                   ` Stefan Monnier
2005-12-03 22:46                     ` Drew Adams
2005-12-02 18:21           ` Richard M. Stallman
2005-12-03 12:08           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=uek4wczxg.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).