bug#23858: 25.0.95; window-state-get doesn't preserve side window status

[martin rudalics]

>> It would be a (slight) penalty for the majority of users who never use
>> side windows.
>
> Can you elaborate? AFAIU it only affects saving and loading of window
> configurations, which isn't used all that much, and we're only talking
> about reading and setting a window parameter. I could be mistaken, but
> the penalty sounds negligible to me.

Eli explained why persistent window parameters may incur a penalty.  But
the problem is not only with the 'window-side' parameter or any of the
parameters cited so far.  If we made 'window-side' persistent, we would
set a precedent that others could follow.  Not that overly many window
parameters have been added recently ...

>> A more stringent problem is that I wouldn't know what to
>> do with other window parameters like 'quit-restore', 'window-atom',
>> 'delete-window', 'other-window'?  Wouldn't it be inconsistent to add
>> only these two to the list of persistent parameters?
>
> To my understanding, these are all part of the window configuration. If
> these parameters are changed, the window's behavior changes. Thus, if the
> parameters aren't persistent, the loaded window configuration is
> slightly different than the saved one. I'm not familiar with all the
> existing window parameters, but as long as their values can persisted
> I'd assume the parameters should be persistent.

Agreed.  Just that I'm not sure whether we should include them in the
default value of ‘window-persistent-parameters’.  My initial idea was
that side windows should be used only by specialized packages that would
provide suitable functions to create, handle and destroy side windows,
install the necessary window parameters, and take care of desktop-saving
these parameters by making them persistent

Only later I added the functions ‘display-buffer-in-side-window’ and
‘display-buffer-in-atom-window’ and these are problematic indeed: If a
user has chosen one of these functions to display a buffer, she's also
entitled to expect the restoration of the corresponding window's status
in a future session.

> I assume you're referring to the discussions around March and April
> 2008.

Correct.  That thread was the incentive for the window state and side
window functions and ‘other-window’, ‘delete-other-window’, ...  related
changes and parameters.

> I've read some of them[1][2][3][4] and it was quite interesting. I
> don't understand why only the state of the major non-side window is
> supposed to be saved. 'window-state-get' seems an excellent way to get
> the window configuration of both the entire frame and "just" a branch of
> the frame's window tree.

IIRC the idea was to keep things transparent: the "major non-side
window" (I apologize for the awkward nomenclature, but nobody really
cared to improve it) represents what the user has when she doesn't use
side windows and what she expects to be saved by ‘desktop-save’ today.

In a future session the major window could be either (1) embedded in a
completely different IDE-like environment with a different arrangement
of side windows or (2) blown up fully to fill the entire frame when
working without any IDE-like environment.  Neither (1) nor (2) are
easily possible if you also save side windows to the desktop file.

Obviously, for (1) and (2) to work, the desktop saving routines would
have to explicitly drop side windows from the window state.  Presently,
they save the side windows but do not preserve their side window state
which is incoherent, at least.  Hence - whatever we decide to do - the
present routines have to be fixed somehow.  Note that the frame/window
handling part of ‘desktop-save’ was written after the introduction of
side windows and I never looked into how to integrate them well.

> First, because different (theoretical) perspectives can have different
> side windows. For example, a "coding" perspective would display an
> source file in the main window and an overview in a side window, while a
> "debugging" perspective could display watched variables in a different
> side window.
>
> Second, because it's possible that the user will sometime want to see a
> side window (for example an overview of source file) and sometimes not.
> Part of the perspective's state in this case would be weather the side
> window is displayed or hidden. Using 'window-state-get' is a good way of
> getting the entire window configuration, including the side window's
> state. I'm imagining a situation where there's a shortcut to toggle
> visibility of the side window.

Agreed.  But I expected that all these issues should be addressed
individually by the package based on side windows including what should
go into the state saved by ‘window-state-get’ and restored by
‘window-state-put’.

>> Out of curiosity: Which kinds of buffers do you display on the left?
>
> Currently I'm trying to put NeoTree[5] and imenu-list[6] on the left side,
> one
> beneath the other,

Does that work?  Is it practicable?  Personally, I'm using an approach
where for _any_ normal window I can display its buffer's tags or file
companions as part of an atomic window.  That is, I can have as many
imenu windows on my frame as there are "normal" windows on it.  The
"one-only" files/imenu side window approach is too annoying for me
because when selecting another "normal" window I would essentially have
to update the contents of the side window according to the normal
window's buffer.

> and testing how well that works with other features
> and packages that I'm using, such as Eyebrowse[7] and persp-mode[8].

Both packages use the window state functions for saving and restoring
configurations within one and the same session.  From their POV _all_
window parameters should be saved and restored too.  Alas there's no
suitable mechanism to do so, presently.  Maybe we should permit also the
values t, 'writable' and nil for ‘window-persistent-parameters’: these
would act on all window parameters present.

Anyway, both packages lose buffer navigation facilities because the
window state functions do not save and restore a window's previous and
next buffers.  Also, the state based functions do not preserve window
identities, so the 'clone-of' parameter might have to be used.  In any
case, substituting the window state functions for the window
configuration functions does not work as seamlessly as someone might
expect.

martin