all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eric Abrahamsen <eric@ericabrahamsen.net>, emacs-devel@gnu.org
Subject: Re: Manual suggestions for quit-restore documentation
Date: Sun, 05 Mar 2017 11:09:31 +0100	[thread overview]
Message-ID: <58BBE3DB.7000000@gmx.at> (raw)
In-Reply-To: <87varoh5ka.fsf@ericabrahamsen.net>

 > I've attached a diff with my edits; if/when some version of this is
 > eventually approved I can do a proper commit.

Thanks.  Please install.

 > I didn't add anything in the Window Parameters section about the first
 > two elements of the quit-restore parameter, simply because I don't
 > understand them well enough. I still think something should be said
 > there about how they influence quit behavior, though -- this is the
 > first place that people will look to find out how this works, and the
 > current docs are very clear about "what", but beg the question of "why".

Trying to recall.

      The first element is one of the symbols `window', meaning that the
      window has been specially created by `display-buffer'; `frame', a
      separate frame has been created; `same', the window has displayed
      the same buffer before; or `other', the window showed another
      buffer before.

If the first element is `window', we usually want to delete that window
but have to cater for a few special cases: For example, the window might
have become the only window on its frame since it was created in which
case we cannot simply delete the frame.  Or, the user might have
switched to another buffer in it in which case calling ‘quit-window’
probably should do just nothing.

If the first element is `frame', the situation is similar to the former
just that we now have to cater for the case that the window is no more
the only one on its frame in which case the frame should probably not be
deleted.

`same' is more tricky: We want to do certain things only if a window
always displayed the same buffer.  For example, automatic resizing of
the *help* window (via ‘temp-buffer-resize-mode’) should happen only if
that window was created specially for *help* and was subsequently reused
for *help* only.  If the *help* window was showing another buffer before
or in between, no such resizing should occur.

`other' signals more or less that the user has restricted the way new
pop-up windows/frames can be created and the (typically second on the
frame) window was (and probably will be) used for showing another
buffer.  In this case we usually do not delete the window, even if after
a sequence of `quit-window' calls the first buffer ever shown in that
window reappeared (we do not remember that much).

      The second element is either one of the symbols `window' or
      `frame', or a list whose elements are the buffer shown in the
      window before, that buffer's window start and window point
      positions, and the window's height at that time.

The values `window' and `frame' for the second element are redundant
IIRC.  Maybe we could as well leave them nil.  Iff the second element is
a list, it tells how to show the "other" buffer that was shown in that
window before when the window is quit.  That's important when that other
buffer appears in yet another window at the time of quitting - we may
want to restore the old `window-point' and `window-start' position, if
possible.

martin




  parent reply	other threads:[~2017-03-05 10:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-05  1:32 Manual suggestions for quit-restore documentation Eric Abrahamsen
2017-03-05  2:14 ` Drew Adams
2017-03-05  4:37   ` Eric Abrahamsen
2017-03-05  4:39     ` Eric Abrahamsen
2017-03-05 10:09     ` martin rudalics
2017-03-05 10:09 ` martin rudalics [this message]
2017-03-05 17:24   ` Eric Abrahamsen
2017-03-23 19:49   ` Eric Abrahamsen
2017-03-24  9:03     ` martin rudalics
2017-03-24 15:44       ` Eric Abrahamsen
2017-03-24 18:52         ` martin rudalics
2017-03-24 19:17           ` Eric Abrahamsen
2017-03-25  9:24             ` martin rudalics
2017-03-25 16:57               ` Eric Abrahamsen
2017-03-26  8:39                 ` martin rudalics
2017-03-26 14:49                   ` Eli Zaretskii
2017-03-26 15:33                     ` Eric Abrahamsen
2017-03-26 16:27                       ` Eli Zaretskii
2017-03-26 23:40                         ` Eric Abrahamsen

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

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

  git send-email \
    --in-reply-to=58BBE3DB.7000000@gmx.at \
    --to=rudalics@gmx.at \
    --cc=emacs-devel@gnu.org \
    --cc=eric@ericabrahamsen.net \
    /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 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.