From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#23858: 25.0.95; window-state-get doesn't preserve side window status Date: Mon, 04 Jul 2016 11:11:01 +0200 Message-ID: <577A2825.2030805@gmx.at> References: <57723464.50603@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1467623801 12913 80.91.229.3 (4 Jul 2016 09:16:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jul 2016 09:16:41 +0000 (UTC) Cc: 23858@debbugs.gnu.org To: bmag bmag Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 04 11:16:30 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 1bJzvK-0004V8-5p for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Jul 2016 11:12:14 +0200 Original-Received: from localhost ([::1]:46047 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJzvJ-0002AC-IZ for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Jul 2016 05:12:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJzvB-00028X-9l for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 05:12:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJzv7-0006uO-Vi for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 05:12:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJzv7-0006uK-Se for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 05:12:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bJzv7-0007KG-K7 for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2016 05:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Jul 2016 09:12:01 +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.146762347528107 (code B ref 23858); Mon, 04 Jul 2016 09:12:01 +0000 Original-Received: (at 23858) by debbugs.gnu.org; 4 Jul 2016 09:11:15 +0000 Original-Received: from localhost ([127.0.0.1]:36555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bJzuN-0007JH-Gk for submit@debbugs.gnu.org; Mon, 04 Jul 2016 05:11:15 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:51855) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bJzuL-0007J4-Sm for 23858@debbugs.gnu.org; Mon, 04 Jul 2016 05:11:14 -0400 Original-Received: from [192.168.1.100] ([212.95.7.30]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MbbWD-1b3qdK1fqH-00J26P; Mon, 04 Jul 2016 11:11:07 +0200 In-Reply-To: X-Provags-ID: V03:K0:/ATBbKd5IyHjpxo1o7n9txjxGJJ67sJLGs/ukjg0HzV82s2cQXz clX43Exdxqyw8UnZ+12gY+2YdSWHLCsU4QQLh8AqKED/lxG+eerAZvaXEHqG/haUIUQEuKd 3GrJumFHBjV0Taeo9/MbmckjKzX2S8Q7a9nwvzwvNKqmrdugVyda7O1nV9AhWZ9pHgAdqPj bjnu1ZYTRrBA+HA7Bghzw== X-UI-Out-Filterresults: notjunk:1;V01:K0:2H0Ld9Ikahw=:S3Z9wJsj59bjfyjiyBBK61 fznQUdKd6h1lpMTceKSQiIITGSGJ6UuocdKDMGyGNduM61C7S9L+NkER+h+uw8snKs1A7PSf2 JNg2bbIIHqZ1Br9wbvuexeanW48uBqeqEbKjSHl/tWzlOVBeNFVZ8Yitwzq8XJRyGJYiu6Xs7 J6cJgws8ofvjHa/SlggLhG59YPLgr29CR3iiCVbaGgcqBn66cny5MHm1wzMme/82ilpErysYV pRCVvOvFjemxWInr08A+raAwGtYUL0mrJQrYAsQtRJzXfVf2HdNI+ju2Ty5fPQfkCOhXpXzRA DIx5qtNlThegX1jDA3HC0hNaLlYsLvRbBc4B2F/eUnHvG+8iXEezUF99EQASthteF9BiujxgC +2wQKPF/BZqOQp+E8QKFfpJjuj9JextHOWB03JXBTGfhqS1345hV5DykL73yZDaz8lUcUOSzL flFVGQMtFNVXGSncWJnrokTavlDQkNTEQg4TXCCxqC3U5GoOwUGmRcul0A23sfD5trKo+2kEu lZIGCNzkQNxv+lxTBMc8h3KQVHW95hMqKU05Z75MuwJ70A4Sg7leV7J/Tj35mtmIZwM2S/7wL rpG5wMCpHP7U5uJCSQb3h28UXTIbIDm0CPxvozvesaHCuuONcSpg+aupTORYADtBFH5W36Cj0 1lvGFpWoX6nwMnvSJOQddz+bjZt1skddy+Vpag8EC9m5Ndl0BFlXGUpxNl/N6wci8k0GX/4BD bZvlNcHIttguaMJptxVZXId1tPTFfDu5gTXocwHPEDLAEbwY8r9d+sul5uxPudN6Yy6PH4Mx 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:120391 Archived-At: >> It would be a (slight) penalty for the majority of users who never us= e >> 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. I= f > 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 =E2=80=98window-persistent-parameters=E2=80=99. My init= ial 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 =E2=80=98display-buffer-in-side-window=E2= =80=99 and =E2=80=98display-buffer-in-atom-window=E2=80=99 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 =E2=80=98other-window=E2=80=99, =E2=80=98delete-othe= r-window=E2=80=99, ... 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 =E2=80=98desktop-save=E2= =80=99 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 =E2=80=98desktop-save=E2=80=99 was written after the int= roduction 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= =2E > 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 =E2=80=98window-state-get=E2=80=99 and restore= d by =E2=80=98window-state-put=E2=80=99. >> 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 s= ide, > 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 =E2=80=98window-persistent-parameters=E2= =80=99: 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