From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: Add function to rotate/transpose all windows Date: Sat, 28 Sep 2024 11:40:27 +0200 Message-ID: <1bcc1236-0a12-4988-bb77-4cd38fc95b42@gmx.at> References: <87setpdv21.fsf@gmail.com> <86zfnxcg57.fsf@gnu.org> <877cb09ln4.fsf@gmail.com> <9005cccc-7545-4257-b2c0-885a13d3bde2@gmx.at> <86o74aa41b.fsf@gnu.org> <3d4546ac-70d9-4865-b42d-0dc50cb0f3a7@gmx.at> <86zfns6vjw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27781"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: pranshusharma366@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 28 11:40:46 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1suTwT-00074v-9c for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Sep 2024 11:40:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1suTwM-0002HS-Eu; Sat, 28 Sep 2024 05:40:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1suTwH-0002HG-Se for emacs-devel@gnu.org; Sat, 28 Sep 2024 05:40:34 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1suTwF-0000AE-Ma; Sat, 28 Sep 2024 05:40:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1727516428; x=1728121228; i=rudalics@gmx.at; bh=7oSNrPSkw+3EmNxNau5qJsSMLMmVgO5KKBojN2Ow1NY=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=fxvEyNboqp9hoQha4sh+uuSP134P0952Urlez4G1VuzIcKfITjjBdUN6MaeAOJlj wrjoacLREuzUfgXulUaHJIQnaTxcfhhnghYZMa4dLacg/tQkDYpMmYtCyjfpHlbzw oEZ6pt+3s1H+qaxGswSeY5yc9sOZzpONN0+9OFZk+uDctJy33BEfoOc+in8uEHRQ0 8I+Tutt1uGx8BxSPcRe4Qw8EzX5jjx4dg0AeGLfIbhyW3EOzG6UG6Use9ieN8xj9D WQrJI+0frf+MdXIpxs8f4BvCtBJVD0WQ6hU7UCavQtAKCoIY08Xv3eFR6qmORJ9ii 4S+FAJCbgTebPZGLZQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([212.95.5.151]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N4QwW-1rt3gw1vfS-015Au9; Sat, 28 Sep 2024 11:40:28 +0200 Content-Language: en-US In-Reply-To: <86zfns6vjw.fsf@gnu.org> X-Provags-ID: V03:K1:V8OAwXApeaoEbKVRmRohZ/ElrhWuj5t2jLD1h4aSIbnQHrRWHhU FuyhCcHIl3pzZAQl5J65r5GsCZ+OQNyNwTkp43vVzbG0csu660OFLGoO7mNkUOD052u6HxI FBpYGMrRLGNEymjUllkX8Wqngo5sox3OgFT8cJM9pf1/7fzj/PMjAsM5NqpE1jzCdmsX38M wLZ9AWbjfX74SfINHRrbA== UI-OutboundReport: notjunk:1;M01:P0:34E/vraQ2RY=;797OC79fJsMBrU1+5UqhyL8QDTJ Hbbb3LrFER390fItEdpaOV/aglh5i+y6caZU2gGUTNOrSuJ4cDB7M0fUqXhBc92OPGQ460LR9 zK21DCUOf6TrBlQjg5//+gjuPsQique+M6Jzmmu+e1NBdqJMxhxN/KVLJOC0Focw+A4WcooUA xRMoRclDI4KRojXCs3+TjcY+Pnb0HSyGpXOAOu8H7nwJW0kyC5Mk07leynOmrbmF8ULomApeG EIma/kT4Tkl+KXSxeVbbmW03R5VYnfy9VDpQCCuAm5+gPcEQm7+/kUTA/0u4jK1OlFjhzyETD oh56EJRN8YnKMz1uOzHoKAdGz0p+yqMyMwJAKLEVSCi7M6GE6BCnImHRNiBgRHL9NhLjqAC0D SGL1esZXYCsDBJKV3XCp+JSHjPfAqHxUhWFgiy0XdQUpHK5FdR/P0tnjVLDb8cqa3jQRM2rt/ D7bCsUjztxjvU1y3BFouYiy9NuvtNpye1+SdcIQzu2lyz30UCQ429Qta5S9zyU+EKZa6zIMw1 /+ELKSNTtkisoFG/3zoLrqC3/E9kBM0ZB/+scSPX6d6cfrCn1MZjPC++IRv02qQMUzLNScddx m1jCaLFx3Kkl29n2Ur0BMlOiEtJ5o4ESXMHXEi59Cr7pqvxkrhL4JJGVbsLTs4Z5RIY8y6iBx h4lstqzTZxWYyWteEYRaYr6foZG7iDFKPfcV4/Rtfcp7KMvLECQKHZLkTQSR+fG8+T+mcgzjF tnn6WJsAhfOU2aHpR3JSETmlxaOVvwW6xflG4kYRVKmm9d8O5P11kziNx3ELY3OsPefda93R Received-SPF: pass client-ip=212.227.15.19; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324162 Archived-At: > Thanks, but does it really make a lot of sense to make this a > side-effect of splitting a window? It makes sense because (1) we do not have to make a new window that gets deleted right away and (2) the geometry of the new window will be handled by 'split-window' directly and not by some obscure copying routine (I only later noted that 'resurrect-window' got me warnings about memcpy combined with offsetof writing beyond the bounds of window structures). > (If it makes sense due to > technical reasons, such as commonality of code of the implementation, > we could have a common internal subroutine with 2 separate APIs > exposed to Lisp.) We can write a separate 'split-window-reuse-existing' function and have it call a 'split-window-reuse-existing-internal' routine so we don't compromise the present 'split-window' at all. It's up to you what you like more. > Or maybe it _will_ make a lot of sense if you reword the doc string so > that it explains why what we do with REFER is a variant of splitting a > window. Something like > > Instead of making a new window, this function can reuse an existing > dead window... OK. > Btw, "dead window" is mentioned only once in the ELisp manual, and > even that in passing, so it is not a very clear terminology, and might > need clarifications in this case. The problem is that in Emacs a live window is a window that shows a buffer. Which implies that internal windows are dead. I once tried to convince Chong that this terminology is misleading but he didn't allow me to change it. >> +If the optional fifth argument REFER is non-nil, it has to denote a >> +dead, former live window on the same frame as OLD or an arbitrary live >> +window. ^^^ > > What is "OLD" here? It should be WINDOW. OLD is the term used by 'split-window-internal'. > More generally, I don't think I understand what > you wanted to say by "or an arbitrary live window". That's a separate functionality to give users more control of the window the new window inherits properties from. It's useful when splitting an internal window and the _new_ window should get its initial buffer and other properties from any but the frame's selected window. >> In the first case, REFER will become the new window with >> +properties like buffer, start and point, decorations and parameters as >> +to the last time when it was live. In the latter case the new window >> +will inherit properties like buffer, start and point, decorations and >> +parameters from REFER. > > I suggest to describe each case separately, i.e. split the previous > sentence ("it has to denote ... or ...") into two, and explain > separately what happens in each case, instead of complicating with the > former and the latter. Especially as there are additional cases (nil > or omitted), which add to the confusion: I'll try to do that. >> +If REFER is nil or omitted, then if WINDOW is live, any such properties >> +are inherited from WINDOW. If, however, WINDOW is an internal window, >> +the new window will inherit these properties from the window selected on >> +WINDOW's frame. > >> + if (!BUFFERP (r->old_buffer)) >> + error ("Dead reference window was not a live window"); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > This seems to imply that the function expects a dead window to be a > live window(??). In our misleading terminology a dead window can be either (i) a former live window or (ii) an internal or former internal window. I have to exclude (ii) because an internal window should never become a leaf window and vice-versa. >> + else if (!BUFFER_LIVE_P (XBUFFER (r->old_buffer))) >> + error ("Dead reference window's old buffer is dead"); > > Will users understand what is "old buffer" of a window? It's the buffer returned by 'window-old-buffer'. I will have to explain this in more detail. >> + else if (!EQ (r->frame, frame)) >> + error ("Dead referenec window was on other frame"); > ^^^^^^^^^ > Typo. Also, I'd say "was on a frame other that that of window being > split" or something like that. OK. >> + dead = true; >> + } >> + else if (!WINDOW_LIVE_P (refer)) >> + error ("Reference window must not be internal"); > > Are we sure "internal" here will be understood? How about using "leaf > window" instead? But it's the opposite - a "non-leaf window". If you (or anyone else) have any proposals on how to improve the nomenclature in this area, I'll be all ears. > More generally, the text of these error messages is not easily > correlated to the problematic argument, because it neither mentions > the argument by its exact name, nor mentions the problematic window by > any other specific reference. So the error messages should explain in more detail what when wrong. >> + /* Provisorially set new's buffer to that of the reference window, > ^^^^^^^^^^^^^ > Did you mean "provisionally"? or maybe "temporarily"? Both would fit the bill. But this is code that I didn't intend to submit is part of a completely different changeset where the sizes of an individual window would be needed to set up the size hints of frames correctly in set_window_buffer. >> + /* Set buffer of NEW to buffer of reference window. We have to do it >> + here so the sizes of NEW are in place. But be sure to do it before >> + adjusting the frame glyphs - otherwise Emacs may inexplicably loop >> + forever. */ > > This should be more explicit what code below adjusts the frame's > glyphs, because without that this very good comment is less useful > than it could be. Again part of that other changeset. >> unchain_marker (XMARKER (w->start)); >> + wset_old_buffer (w, w->contents); > > What is this about? When we make a new window and delete it before redisplay runs window_change_functions for the first time, the old buffer of the window is nil. But that would have caused the "Dead reference window's old buffer is dead" error with the earlier proposed 'resurrect-window' while in fact the window (made by 'split-window' right before) did have an old buffer. It has no significance for the new 'split-window'. >> @@ -7720,6 +7795,7 @@ delete_all_child_windows (Lisp_Object window) >> only, we use this slot to save the buffer for the sake of >> possible resurrection in Fset_window_configuration. */ >> wset_combination_limit (w, w->contents); >> + wset_old_buffer (w, w->contents); > > And this? Same explanation. The code for Fdelete_window_internal and delete_all_child_windows should be refactored so that they would call a common delete_leaf_window. Thanks for the careful reading, martin