From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: bmag bmag Newsgroups: gmane.emacs.bugs Subject: bug#23858: 25.0.95; window-state-get doesn't preserve side window status Date: Sat, 2 Jul 2016 21:39:10 +0300 Message-ID: References: <57723464.50603@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d458e4a5da00536ab6b10 X-Trace: ger.gmane.org 1467484883 4304 80.91.229.3 (2 Jul 2016 18:41:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Jul 2016 18:41:23 +0000 (UTC) Cc: 23858@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 02 20:41:10 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bJPqn-000073-Ju for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Jul 2016 20:41:09 +0200 Original-Received: from localhost ([::1]:39725 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJPqm-0007PW-KZ for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Jul 2016 14:41:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJPpo-0006FD-5L for bug-gnu-emacs@gnu.org; Sat, 02 Jul 2016 14:40:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJPpi-0001zf-Qa for bug-gnu-emacs@gnu.org; Sat, 02 Jul 2016 14:40:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJPpi-0001zb-LQ for bug-gnu-emacs@gnu.org; Sat, 02 Jul 2016 14:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bJPpi-0006h2-FV for bug-gnu-emacs@gnu.org; Sat, 02 Jul 2016 14:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: bmag bmag Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Jul 2016 18:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23858 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23858-submit@debbugs.gnu.org id=B23858.146748475825677 (code B ref 23858); Sat, 02 Jul 2016 18:40:02 +0000 Original-Received: (at 23858) by debbugs.gnu.org; 2 Jul 2016 18:39:18 +0000 Original-Received: from localhost ([127.0.0.1]:34859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bJPp0-0006g4-A4 for submit@debbugs.gnu.org; Sat, 02 Jul 2016 14:39:18 -0400 Original-Received: from mail-yw0-f172.google.com ([209.85.161.172]:35258) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bJPoy-0006fq-ES for 23858@debbugs.gnu.org; Sat, 02 Jul 2016 14:39:16 -0400 Original-Received: by mail-yw0-f172.google.com with SMTP id l125so12543865ywb.2 for <23858@debbugs.gnu.org>; Sat, 02 Jul 2016 11:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pc3v6hDprsAf4Thb3lLZNnbO2qmDHmfydd1dWUbVNNE=; b=y+alf3B30XF2ago5R9SfrsEQ6IpOvrsbkMExm+QmojAQFTpx9PV9zSiYsgYqkcBezT GGxAjyfh4VUBSBuK6qXLFi7JJkpptLOgHDSh8qwkTFkw7NqRRKhEZkBxCtR6omUo6kPf 0jc+MV8lVsl6lYFMSJgbnZI/Dy8DDZqZd76OeyY2rP+LGXKSG+pA6eTlACZb0Y2NM3FW TmsQ/m2dnZbME+qEtZloO+8deP12s0ideWQ12B61rHyXr7JmSk5BMBRPplQtaOzv5G3U 5KnC1YPuPdrNCfOhtA0+ucYSVfj3Czr+DnWf3MhlXE6T++FVzbg/cZ6VSI/jBGDfWh3/ TPQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pc3v6hDprsAf4Thb3lLZNnbO2qmDHmfydd1dWUbVNNE=; b=CwyEeoQgrKIaZfgvVrR+4lBRs0xmYr3K8v4AMWyX94kGZRDiJnJ6UJzGeCflSEKf6s y3B2IDf/ukHta+4Kd88egM3L9kPypzp+jsmEV0gJ2eFslPWUCIqLgN0DTfJAvlyIg/wc +b/xjlDaCpHLMQhB4ExqdBM5aM+TQyWsB4J0U50b8dbbFjGq6ZkF9OUHqMux9DCk9NQG BFFfiLZ5XSElGMxY+NZvblhtn0J1fyN2NTdDg5XssIvWFWnmGhcC3zcacvuFagopu1Im v1RcMPFXvwE/ix1Gwc9LO6TnJY8L4cqCmyH0GoysQmTO12EOGXUCj5R2gwkdtaWUcG32 pzcQ== X-Gm-Message-State: ALyK8tJbRgQzVuJ6QpuGvlTQEa9frnL6w+S/2tEYe9b9c6pNNYRuV4i3f3dohpmtdze5XyOigjklgH60d/pmUg== X-Received: by 10.37.37.11 with SMTP id l11mr2545407ybl.16.1467484750894; Sat, 02 Jul 2016 11:39:10 -0700 (PDT) Original-Received: by 10.13.229.4 with HTTP; Sat, 2 Jul 2016 11:39:10 -0700 (PDT) In-Reply-To: <57723464.50603@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:120302 Archived-At: --001a113d458e4a5da00536ab6b10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=98window-state-get=E2=80=99 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 =E2=80=98desktop-save=E2=80=99 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 --001a113d458e4a5da00536ab6b10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First of all, thanks for the reply. Now for the matter at = hand:

> It would be a (slight) penalty for the majority of u= sers 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 sett= ing a window parameter. I could be mistaken, but
the penalty sounds negl= igible to me.

> A more stringent problem is that I wouldn't k= now what to
> do with other window parameters like 'quit-restore&= #39;, 'window-atom',
> 'delete-window', 'other-wi= ndow'?=C2=A0 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 chang= ed, 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 parame= ters, but as long as their values can persisted
I'd assume the param= eters should be persistent.

> The major obstacle though is that s= ide windows conceptually should not
> be saved by =E2=80=98window-sta= te-get=E2=80=99 at all.=C2=A0 This was part of the IDE concept
> disc= ussed on emacs-devel many years ago: The window states to save and
> = restore are those of the interior (non-side) windows.=C2=A0 Normally, the> side windows would stay arranged permanently around the major non-si= de
> window and only the contents of the latter would change accordin= g to
> what the user prefers to work on.

I assume you're r= eferring to the discussions around March and April
2008. I've read s= ome of them[1][2][3][4] and it was quite interesting. I
don't unders= tand why only the state of the major non-side window is
supposed to be s= aved. 'window-state-get' seems an excellent way to get
the windo= w configuration of both the entire frame and "just" a branch ofthe frame's window tree.

First, because different (theoretical= ) perspectives can have different
side windows. For example, a "cod= ing" perspective would display an
source file in the main window an= d an overview in a side window, while a
"debugging" perspectiv= e could display watched variables in a different
side window.

Sec= ond, because it's possible that the user will sometime want to see aside 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 go= od way of
getting the entire window configuration, including the side wi= ndow's
state. I'm imagining a situation where there's a shor= tcut to toggle
visibility of the side window.

> Out of curiosi= ty: Which kinds of buffers do you display on the left?

Currently I&#= 39;m trying to put NeoTree[5] and imenu-list[6] on the left side, one
be= neath 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 th= e 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.=C2=A0 Does it work?=C2=A0 Did you ever
> = test it via the =E2=80=98desktop-save=E2=80=99 feature?

I'm test= ing via 'eyebrowse-switch-to-window-config' of the Eyebrowse
pac= kage, 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.ht= ml
[2]: What IDE features are in CEDET?: https://lists.gnu.org= /archive/html/emacs-devel/2008-04/msg01857.html
[3]: Neat features i= n Eclipse editor: https://lists.gnu.org/archive/html/emacs-devel/2008= -03/msg02254.html
[4]: Window configuration UI (was: Neat features i= n Eclipse editor): https://lists.gnu.org/archive/html/emacs-devel/200= 8-03/msg02433.html
[5]: NeoTree: https://github.com/jaypei/emacs-neotree
[6]: imenu-= list: https://github.com/bm= ag/imenu-list/ (I'm the author)
[7]: Eyebrowse: https://github.com/wasamasa/eyebrowse/
[8]: persp-mode: https://github.com/Bad-ptr/persp-mode.el

--001a113d458e4a5da00536ab6b10--