unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: bmag bmag <bmagamb@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: 23858@debbugs.gnu.org
Subject: bug#23858: 25.0.95; window-state-get doesn't preserve side window status
Date: Sat, 2 Jul 2016 21:39:10 +0300	[thread overview]
Message-ID: <CAHYyYN-dUdYRtGFnv=Gu-1e0qeSWxjmA+i6rUqa-cB_QHPqGXw@mail.gmail.com> (raw)
In-Reply-To: <57723464.50603@gmx.at>

[-- 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 --]

  reply	other threads:[~2016-07-02 18:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-27 20:07 bug#23858: 25.0.95; window-state-get doesn't preserve side window status bmag bmag
2016-06-28  8:25 ` martin rudalics
2016-07-02 18:39   ` bmag bmag [this message]
2016-07-02 19:00     ` Eli Zaretskii
2016-07-04  9:11     ` martin rudalics
2016-10-05 12:30 ` martin rudalics

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='CAHYyYN-dUdYRtGFnv=Gu-1e0qeSWxjmA+i6rUqa-cB_QHPqGXw@mail.gmail.com' \
    --to=bmagamb@gmail.com \
    --cc=23858@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /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).