[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help with windows and 'quit-restore

From: martin rudalics
Subject: Re: Help with windows and 'quit-restore
Date: Wed, 01 Mar 2017 21:13:36 +0100

> Whatever the correct technical solution is, both the docs and the code
> are pretty confusing. I think the key piece of missing information re
> quit-restore is that, if there's a history of previously-displayed
> buffers in this window, quitting the displayed buffer will display the
> next buffer in the history. If there *isn't* such a history, quitting
> the buffer will delete the window completely.
> (Is that always true? Are there any other factors that influence this
> behavior?)

I think it's true.

> It's a complicated topic, and probably hard to document. The Window
> History section of the manual mentions previous buffers, but doesn't
> mentioned the connection to quit-restore behavior.
> In Quitting Windows, under the description of `quit-restore-window', it
> says "If WINDOW was created specially for displaying its buffer, this
> function deletes WINDOW..." When I was writing my functions I read that,
> but didn't understand what "created specially" meant. My understanding
> now is that that means there's no previous buffer history, but this
> documentation makes it sound like this is something that happens at
> window creation time, not something you can set later.

‘split-window’ has two connotations: The first one is that a user wants
to see two distinct portions of the same buffer.  The second one is that
the user wants to see two different buffers.  In the second case we
emulate a "pristine" history by pretending that the new window never
showed its initial buffer.  And we do that only for ‘display-buffer’ and
its clients because only in those cases we know for sure that the window
should have shown a different buffer right away.

> Lastly, the quit-restore description in Window Parameters says what the
> parameter elements *are*, but (for the first two elements at least) not
> what they *do*.

Right.  I carefully tried to avoid saying that.  Once created, we change
the contents of the ‘quit-restore’ parameter only when we reuse its
window via ‘display-buffer’.  But we may show another buffer in that
window (and change the history of buffers shown in that window) any
time.  So when ‘quit-restore-window’ gets eventually called, it has to
deal with the situation that the ‘quit-restore’ parameter is out of
date, i.e., presumably no more describes the state of things at the time
it was created.  And in that occasion, the history of buffers previously
shown in that window will prevail.

> Those are three areas where I'd suggest tweaking the docs. I'd be happy
> to provide specific suggestions or patches.

Please do that.

> Lastly, as a shot in the dark, mightn't it make sense to allow
> `display-buffer-record-window' to set the window history? The docstring
> says the purpose of the function is to install or update the
> quit-restore parameter -- wouldn't it make sense to let it set the
> history part of the parameter, too?

Maybe.  But ‘window--display-buffer’ currently does

    (display-buffer-record-window type window buffer) <---
    (unless (eq buffer (window-buffer window))
      (set-window-dedicated-p window nil)
      (set-window-buffer window buffer) <---
      (when dedicated
        (set-window-dedicated-p window dedicated))
      (when (memq type '(window frame))
        (set-window-prev-buffers window nil))) <---

and I'm not sure whether we anywhere might rely on the
‘set-window-prev-buffers’ call following the ‘set-window-buffer’ call.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]