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: Fri, 24 May 2019 14:32:18 -0700 Message-ID: <875zpzedy5.fsf@ericabrahamsen.net> References: <87tvdmqsxq.fsf@ericabrahamsen.net> <0a820a2c-8b37-469e-6b0e-61b126b6c7b8@gmx.at> <87lfyxszb5.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="75460"; 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 Fri May 24 23:40:34 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 1hUHvT-000JOL-75 for ged-emacs-devel@m.gmane.org; Fri, 24 May 2019 23:40:31 +0200 Original-Received: from localhost ([127.0.0.1]:60431 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUHvS-00061e-3T for ged-emacs-devel@m.gmane.org; Fri, 24 May 2019 17:40:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUHvC-0005uE-20 for emacs-devel@gnu.org; Fri, 24 May 2019 17:40:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hUHng-0007c0-Ig for emacs-devel@gnu.org; Fri, 24 May 2019 17:32:30 -0400 Original-Received: from [195.159.176.226] (port=51268 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hUHne-0007Z2-JR for emacs-devel@gnu.org; Fri, 24 May 2019 17:32:28 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hUHnc-0009Vl-Ax for emacs-devel@gnu.org; Fri, 24 May 2019 23:32:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:E8Vqjp3UmZxKHiQzsjq10uxbZ/w= 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:236970 Archived-At: martin rudalics writes: >> Oh I see, thanks. I thought I had to check for the 'window-atom >> parameter on the parent, if there was a parent. > > Atomic windows can be arbitrarily nested so checking for atomicity of > the parent alone is in general not sufficient. That's nuts! In a good way. Thanks for the information. >>> 'quit-window' does not necessarily restore to a state that invalidates >>> the atomicity of the containing group. 'delete-window' OTOH may do >>> that, so if 'quit-window' deletes all windows of an atomic group but >>> one, that atomic group is dissolved automatically. >> >> Hmm, maybe it was `delete-window' that raised the error: >> >> delete-window: Root of atomic window is root window of its frame >> >> Whereas `quit-window' behaves in a way I can't quite pin down -- it >> killed the buffer in one case but not in another, didn't change the >> actual window layout, and moved point to the "first" of the atomic >> windows. > > 'quit-window' calls 'window-deletable-p' before it tries to delete a > window so it should never cause a "Root of atomic window is root > window of its frame" error. If it does cause an error we have a bug > so maybe check again. No, it was `delete-window' that raised the error, as you describe below. `quit-window' just behaved unpredictably. > 'delete-window' OTOH will raise an error when the root of the atomic > window is the root of the frame. If you want to avoid that, typically > because most of your users who type C-x 0 expect the selected window > to disppear or those typing C-x 1 expect the selected window to become > the single window of its frame despite of atomicity, you will have to > adjust the behavior with the help of 'delete-window' and > 'delete-other-windows' parameters for all involved windows. This is really helpful, and I see that the docstring of `delete-window' actually mentions the case of atomic windows. I agree with Eli that maybe more documentation is in order. I feel like all the pieces are present (here and there), but there's no one place to get a full overview. Thanks, Eric