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

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

[bmag bmag]

[-- Attachment #1: Type: text/plain, Size: 4264 bytes --]

Calling 'window-state-get' to store a side window (or a window-tree that
contains a side window) and later calling 'window-state-put' to restore
the window doesn't keep the window's status as a side window. In other
words, the 'window-side' and 'window-slot' window paramters are not
saved and restored by 'window-state-get' and 'window-state-put'.

I found that by adding the window parameters to
'window-persistent-parameters' (details below), then 'window-state-get'
and 'window-state-put' do save and restore the side window's status as a
side window. Doesn't it make sense to add 'window-slot' and
'window-side' to the default value of 'window-persistent-parameters'? Is
there a reason why it's not the case already?

Thanks,
Bar

recipe:
1. emacs -Q
2. evaluate (e.g. with 'M-:'):
(setq mywin (display-buffer (get-buffer-create "buff1")
'(display-buffer-in-side-window (side . left) (slot . 0))))
3. evaluate:
(window-parameter mywin 'window-side)
returned value: left
4. evaluate:
(window-state-put (window-state-get mywin t) mywin)
5. evaluate:
(window-parameter mywin 'window-side)
returned value: nil
expected value: left

The 'window-slot' window-parameter is likewise reset from 0 to nil at
step 4.

How I modified 'window-persistent-parameters' to fix the problem:
(add-to-list 'window-persistent-parameters '(window-side . writable))
(add-to-list 'window-persistent-parameters '(window-slot . writable))





In GNU Emacs 25.0.95.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
 of 2016-06-27 built on matrix
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:    Ubuntu 16.04 LTS

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_MONETARY: he_IL.UTF-8
  value of $LC_NUMERIC: he_IL.UTF-8
  value of $LC_TIME: he_IL.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
next-line: End of buffer
Mark set
((window-side . writable) (clone-of . t))
((window-slot . writable) (window-side . writable) (clone-of . t))
#<window 8 on buff1>
left
nil
left
Quit [2 times]
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 89002 9010)
 (symbols 48 19908 0)
 (miscs 40 521 171)
 (strings 32 14980 4488)
 (string-bytes 1 440881)
 (vectors 16 12224)
 (vector-slots 8 438921 6034)
 (floats 8 168 256)
 (intervals 56 219 11)
 (buffers 976 13)
 (heap 1024 36895 1038))

[-- Attachment #2: Type: text/html, Size: 4899 bytes --]

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

[martin rudalics]

 > Calling 'window-state-get' to store a side window (or a window-tree that
 > contains a side window) and later calling 'window-state-put' to restore
 > the window doesn't keep the window's status as a side window. In other
 > words, the 'window-side' and 'window-slot' window paramters are not
 > saved and restored by 'window-state-get' and 'window-state-put'.

Correct.

 > I found that by adding the window parameters to
 > 'window-persistent-parameters' (details below), then 'window-state-get'
 > and 'window-state-put' do save and restore the side window's status as a
 > side window. Doesn't it make sense to add 'window-slot' and
 > 'window-side' to the default value of 'window-persistent-parameters'? Is
 > there a reason why it's not the case already?

It would be a (slight) penalty for the majority of users who never use
side windows.  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?

The major obstacle though is that side windows conceptually should not
be saved by ‘window-state-get’ at all.  This was part of the IDE concept
discussed on emacs-devel many years ago: The window states to save and
restore are those of the interior (non-side) windows.  Normally, the
side windows would stay arranged permanently around the major non-side
window and only the contents of the latter would change according to
what the user prefers to work on.

Alternatively, the side windows could be removed temporarily to give the
user the entire frame estate for editing.  In that case, the side
windows would have to be regenerated from scratch whenever the user
wanted to see them again.  While inconvenient for the application
programmer, I was told that the existing IDEs did that already and I
also had no good idea of how to save/restore the state of side windows
only w/o also saving/restoring the state of the major non-side window.

I'm not sure wheter you can follow these arguments - feel free to ask
whenever you find something incomprehensible ...

 > 1. emacs -Q
 > 2. evaluate (e.g. with 'M-:'):
 > (setq mywin (display-buffer (get-buffer-create "buff1")
 > '(display-buffer-in-side-window (side . left) (slot . 0))))

Out of curiosity: Which kinds of buffers do you display on the left?

 > 3. evaluate:
 > (window-parameter mywin 'window-side)
 > returned value: left
 > 4. evaluate:
 > (window-state-put (window-state-get mywin t) mywin)
 > 5. evaluate:
 > (window-parameter mywin 'window-side)
 > returned value: nil
 > expected value: left
 >
 > The 'window-slot' window-parameter is likewise reset from 0 to nil at
 > step 4.

I'd prefer to remove the parameter in this case but so far was too lazy
to implement that.

 > How I modified 'window-persistent-parameters' to fix the problem:
 > (add-to-list 'window-persistent-parameters '(window-side . writable))
 > (add-to-list 'window-persistent-parameters '(window-slot . writable))

This is IMO the correct way to handle this.  Does it work?  Did you ever
test it via the ‘desktop-save’ feature?

martin

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

[bmag bmag]

[-- Attachment #1: Type: text/plain, Size: 4305 bytes --]

First of all, thanks for the reply. Now for the matter at hand:

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

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

> The major obstacle though is that side windows conceptually should not
> be saved by ‘window-state-get’ at all.  This was part of the IDE concept
> discussed on emacs-devel many years ago: The window states to save and
> restore are those of the interior (non-side) windows.  Normally, the
> side windows would stay arranged permanently around the major non-side
> window and only the contents of the latter would change according to
> what the user prefers to work on.

I assume you're referring to the discussions around March and April
2008. 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.

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.

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

> > How I modified 'window-persistent-parameters' to fix the problem:
> > (add-to-list 'window-persistent-parameters '(window-side . writable))
> > (add-to-list 'window-persistent-parameters '(window-slot . writable))
>
> This is IMO the correct way to handle this.  Does it work?  Did you ever
> test it via the ‘desktop-save’ feature?

I'm testing via 'eyebrowse-switch-to-window-config' of the Eyebrowse
package, which uses 'window-state-put' and 'window-state-get' on the
frame's root window with non-nil 'writable' argument.

[1]: patch for optional inhibit of delete-other-windows(IDE feature):
https://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01867.html
[2]: What IDE features are in CEDET?:
https://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01857.html
[3]: Neat features in Eclipse editor:
https://lists.gnu.org/archive/html/emacs-devel/2008-03/msg02254.html
[4]: Window configuration UI (was: Neat features in Eclipse editor):
https://lists.gnu.org/archive/html/emacs-devel/2008-03/msg02433.html
[5]: NeoTree: https://github.com/jaypei/emacs-neotree
[6]: imenu-list: https://github.com/bmag/imenu-list/ (I'm the author)
[7]: Eyebrowse: https://github.com/wasamasa/eyebrowse/
[8]: persp-mode: https://github.com/Bad-ptr/persp-mode.el

[-- Attachment #2: Type: text/html, Size: 5330 bytes --]

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

[Eli Zaretskii]

> From: bmag bmag <bmagamb@gmail.com>
> Date: Sat, 2 Jul 2016 21:39:10 +0300
> Cc: 23858@debbugs.gnu.org
> 
> > 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.

Not necessarily: these functions are used by frameset.el, which is
used by desktop.el, and the latter auto-saves the window and frame
configurations every 30 sec by default.

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

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

[martin rudalics]

 > Calling 'window-state-get' to store a side window (or a window-tree that
 > contains a side window) and later calling 'window-state-put' to restore
 > the window doesn't keep the window's status as a side window. In other
 > words, the 'window-side' and 'window-slot' window paramters are not
 > saved and restored by 'window-state-get' and 'window-state-put'.
 >
 > I found that by adding the window parameters to
 > 'window-persistent-parameters' (details below), then 'window-state-get'
 > and 'window-state-put' do save and restore the side window's status as a
 > side window. Doesn't it make sense to add 'window-slot' and
 > 'window-side' to the default value of 'window-persistent-parameters'? Is
 > there a reason why it's not the case already?
 >
 > Thanks,
 > Bar
 >
 > recipe:
 > 1. emacs -Q
 > 2. evaluate (e.g. with 'M-:'):
 > (setq mywin (display-buffer (get-buffer-create "buff1")
 > '(display-buffer-in-side-window (side . left) (slot . 0))))
 > 3. evaluate:
 > (window-parameter mywin 'window-side)
 > returned value: left
 > 4. evaluate:
 > (window-state-put (window-state-get mywin t) mywin)
 > 5. evaluate:
 > (window-parameter mywin 'window-side)
 > returned value: nil
 > expected value: left
 >
 > The 'window-slot' window-parameter is likewise reset from 0 to nil at
 > step 4.
 >
 > How I modified 'window-persistent-parameters' to fix the problem:
 > (add-to-list 'window-persistent-parameters '(window-side . writable))
 > (add-to-list 'window-persistent-parameters '(window-slot . writable))

‘display-buffer-in-side-window’ now makes the `window-side' and
`window-slot' parameters persistent.  So I'm closing this bug.

Thanks, martin