From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Understanding atomic window groups Date: Tue, 4 Jun 2019 10:20:19 +0200 Message-ID: <52ea0859-0e57-b2a9-5798-8328596b9630@gmx.at> References: <87tvdmqsxq.fsf@ericabrahamsen.net> <0a820a2c-8b37-469e-6b0e-61b126b6c7b8@gmx.at> <87lfyxszb5.fsf@ericabrahamsen.net> <875zpzedy5.fsf@ericabrahamsen.net> <171bed6b-96d6-0fa0-f4f4-b09cb72c7192@gmx.at> <87lfyucxfx.fsf@ericabrahamsen.net> <26d5d317-df88-fed9-1eb5-e5f0cb07bd25@gmx.at> <878suibcu8.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="135409"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 04 10:26:53 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hY4mS-000Z7o-MJ for ged-emacs-devel@m.gmane.org; Tue, 04 Jun 2019 10:26:52 +0200 Original-Received: from localhost ([127.0.0.1]:48534 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hY4mR-0004RX-NE for ged-emacs-devel@m.gmane.org; Tue, 04 Jun 2019 04:26:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hY4lh-0004RO-Ed for emacs-devel@gnu.org; Tue, 04 Jun 2019 04:26:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hY4lf-000417-5R for emacs-devel@gnu.org; Tue, 04 Jun 2019 04:26:04 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:35205) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hY4le-0003uT-5l for emacs-devel@gnu.org; Tue, 04 Jun 2019 04:26:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1559636743; bh=O4PqzzZgchmUAtjRVUR2NBlcB9W7n3UUKjIPxBBvK/0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ALwrxHErcy373zndEHQfUD9ZRVqvmv+A/zhWqUD+x6hXvOpRGnxUWXku9YxtzrvMH 83TrCgaE0aEVbrTIrBhPeikvNVTddJ1CzPYBk3BaJxdkXARqeEuTxlTfypOY+XKeWF /VesHD5gp03bIU2Snc4AeQrL1y7XgEHfykIbX9NE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.222]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lk7T8-1h0eo23sBW-00cCgs; Tue, 04 Jun 2019 10:20:21 +0200 In-Reply-To: <878suibcu8.fsf@ericabrahamsen.net> Content-Language: de-DE X-Provags-ID: V03:K1:/RxoPiZrg5S9Ifx6HGT6J1y1iAPncIOHwr6a5UNHFmDh1xJhJ0W FCFQj9hcTyet2JhhMYOaftmUjSgNocXBBAzEkGfhMdqC8HUIWLCvYYR8EGOUvwBdPn3wY7V BgfTATm5J9pyRq7s27Aqw9zsU2ryN6D/+957tMgYDUiSdEjn4Bj4iySoFTPd+ZId6cTvs66 Lp5/eBznogft0w7dJq1Lw== X-UI-Out-Filterresults: notjunk:1;V03:K0:PznEfG5Y/GU=:whca6hVksIxzn3lMv8tIbs u1+h072OaBf+NALrPFcGY9bHl4cp+MeueVjwZX1MuWARuS/lgNuYPp0iy7HFJrVYwFOIkQRVm GHjetuDWbrDPnTaZEDWwAKYP9EHGRJr39dXuUCmQ5iTacRf/I6fYEo2ttQibKlXoR5BJ6O2nh XCi1naVDxFizkf16i4Eh2giBK8eXgWLjC4AmyTJgbjhwK9ucK5k+vz+GlxHZtKp1nD13d8KHM w4rAKvK0ZA991sQgX8TdXtWZuVBWmkRSdYdNCd8fDWmSEX2d0MB+SKssyO3MXPQRMpusAPEdG Ml710D/7lriMFPIRQcQG/YK0vhAXkJ+77J1yGiuLpNTxrxUTKshtPlCiIx35aCFZq/GG2x/T9 Pf00oGJB/LytzmbqdyfScV74j9/enOONNi0gLpj4CxATcjoviWyHiW9zybbiWbqc6Tptq5Hqj Iq4lBmg+bKJRUoTiRN15vBF+945MrcryCd/5ZBFxN4O167Ku0EEVQwpFQZQGZCPPVTWOCk+6i /lNRMTYTXg+a9FMGQ71rGzn7oktOCVEiUPNWG/BAcYSNXx6TwZUCv1steL0Vek9bytx9Ym2o/ /usVrOOA/aJZkQoqbRuv+HFUCEZPtE5sxOMuwKhnaVdcJ5gkLhNedMlkZQamUePrUQVOYPJ2e fzagjXxPDNCKwFZS959g/zHdaseJQaWRfg43oHmnoWW31YSXjrPONH74hG1f2mttkO8tyPnQr GpQmx0n4PHJIwDOT1VBeP3KiEBCRu2UeBf/yZpXuImF/Bwb/CUEnrTHEgQqYFLnOoeMzpi4h X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.18 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:237241 Archived-At: > I was thinking the toggle would first remove the atomic property from = a > group of windows and record the fact that they used to be atomic. The > next call would restore that atomicity. But... recording _how_ they we= re > arranged, and restoring them when the entire frame has possibly been > rearranged in the meantime, sounds onerous and weird. I consider making and dissolving atomic windows rather specific to Gnus and it should be probaly done there. Only if there is a more general need, such functionality should be provided by window.el. > Maybe the `window-dissolve-atom' function you posted above would be > enough. It's not terribly mysterious code, but it is a very useful > utility function, particularly for people who are just getting into > this. I can add it any time. > The typical example looks like: > > +------------------------------+ > | Summary | > | | > +-------------------+----------+- > | | | > | Article | BBDB | > | | | > | | | > +-------------------+----------+ > > Where point is in the Summary window -- that's the "main" window. It's= > possible to put point in the Article or BBDB windows and do things > there, but the Summary keymap contains all kinds of bindings for > operating on the other two windows "remotely". Is BBDB something typical for Gnus? I thought the "group" window is the more typical one. Or maybe the ones for composing messages or articles. > Gnus has many buffers (see `gnus-window-to-buffer'), and many potentia= l > window configurations (the manual lists 22 known possibilities). Where is all that documented? 'gnus-window-to-buffer', for example? I suppose the 22 possibilities are the ones from section 9.5.1 of the Gnus manual. So probably I get some predefined hardcoded layout when doing, say 'gnus-summary-edit-article' and when done with editing the previous layout gets restored. But where is that described? And how can I customize it? Looking at section 9.5 Window Layout: It starts with saying that there are glitches with 'gnus-use-full-window' (which should probably be called 'gnus-use-full-frame'). But wouldn't embedding Gnus' windows in an Emacs frame be one of the primary tasks of the layout mechanism? Next it says that =E2=80=98gnus-buffer-configuration=E2=80=99 describes h= ow much space each Gnus buffer should be given. IMO it should rather say how much space a window like the "summary window" or "article window" are given. Below it even talks about "splitting buffers" ... Also, a sentence like "In a =E2=80=98frame=E2=80=99 split, the last subsp= lit having a leaf split where the tag =E2=80=98frame-focus=E2=80=99 is a member ..." i= s very hard to comprehend - I failed. > The > same buffers might be displayed in different locations in different > configurations, which is why the `display-buffer-alist' approach doesn= 't > seem to fit. I don't think that specifying layouts operationally via "vertical" and "horizontal" splits is bad per se and people are most likely used to it. But I think that some descriptive layer maybe on top of the operational one using terms like "top", "above" or "right" would be more suitable for people using Gnus for the first time. In either case I failed to decipher the layout sketched in section 9.5.2 from the two (why two?) accompanying 'gnus-add-configuration' calls. > It's possible that (as is often the case) Gnus' mechanisms are too > idiosyncratic to be recreated with built-in tools. If so, that's total= ly > fine -- I just thought that, if it were possible, it would be a nice > refactor. I would like to see a comprehensible and more complete documentation of Gnus' windows layouts first. Then we could talk about an alternative, less operational specification of the layout and how to support it with the help of Emacs' core functions. Thanks, martin