From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Understanding atomic window groups Date: Sat, 25 May 2019 10:54:59 -0700 Message-ID: <878suuctcc.fsf@ericabrahamsen.net> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="54285"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 25 19:56:01 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 1hUatk-000DyN-N4 for ged-emacs-devel@m.gmane.org; Sat, 25 May 2019 19:56:00 +0200 Original-Received: from localhost ([127.0.0.1]:44840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUatj-00064k-LV for ged-emacs-devel@m.gmane.org; Sat, 25 May 2019 13:55:59 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUat8-00064f-CO for emacs-devel@gnu.org; Sat, 25 May 2019 13:55:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hUat0-0005NI-OE for emacs-devel@gnu.org; Sat, 25 May 2019 13:55:18 -0400 Original-Received: from [195.159.176.226] (port=43532 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hUasw-0005FA-US for emacs-devel@gnu.org; Sat, 25 May 2019 13:55:12 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hUass-000CzH-Tt for emacs-devel@gnu.org; Sat, 25 May 2019 19:55:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:HJ/5xR3mO2xB+wbJvJLHj39OZSI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:236986 Archived-At: Eric Abrahamsen writes: > martin rudalics writes: > >>> `quit-window' just behaved unpredictably. >> >> The idea behind `quit-window' is that it should _never_ bark at the >> user but silently use the next-best solution when the predefined one >> fails. For example, typing C-h m usually displays a new *Help* >> window. Typing 'q' in that window conceptually deletes that window >> because it did not exist before showing *Help*. But if you do C-x 1 >> in the *Help* window first and then type 'q', that window can't be >> deleted and thus will have to show some other buffer instead. > > Okay, I do see that `quit-window' has a more complicated job to do, and > multiple conditions are checked. I guess I was hoping/expecting that > `quit-window' in a member of an atomic window group could somehow be > altered to act on the whole group, rather than just the current window. For instance! Side windows have `window-toggle-side-windows', maybe we could have something similar for atomic windows? [...] > It would be great to have more examples in the side windows section as > well. The two features together feel like they could be very powerful, > there's just a bit of a documentation gap. > > I've had it in the back of my mind to try replacing Gnus' homemade > windowing functionality with side windows, because they do pretty much > the same thing, but I'm not sure where to start. Just to extend this hypothetical: Gnus configures its various window layouts in `gnus-buffer-configuration', an assoc list where each element looks like: (article (horizontal 1.0 (vertical 0.5 (group 1.0)) (vertical 1.0 (summary 0.25 point) (article 1.0)))) This configuration is selected using 'article as a key -- (gnus-configure-windows 'article) -- the rest of it is arbitrarily nested instructions about how to split the various buffer and how big the splits should be. As a lazy developer, I'd like to be able to pull apart the setting above, find the window with 'point and make that the "main window", and use the rest of the information to issue a series of (probably) `display-buffer-in-side-window' calls that put the rest of the windows in place. It would be particularly nice if we could stick an 'atomic key in the above setting, and have the resulting side window assembly be atomic. Maybe this is totally possible right now, I don't know. Eric