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 16:58:24 +0200 Message-ID: <6521c200-65ff-4ded-933d-10d7c667dc01@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> <1bcc1236-0a12-4988-bb77-4cd38fc95b42@gmx.at> <86v7yg57u3.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="33278"; 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 16:59:14 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 1suYuf-0008XH-Q1 for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Sep 2024 16:59:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1suYu3-0003S9-U4; Sat, 28 Sep 2024 10:58:35 -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 1suYtz-0003Ql-Ez for emacs-devel@gnu.org; Sat, 28 Sep 2024 10:58:31 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1suYtx-0004yy-DH; Sat, 28 Sep 2024 10:58:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1727535505; x=1728140305; i=rudalics@gmx.at; bh=Kk8M+pDIBlKacXE3jjFcZsne0UtObBkSC/OgSbWB78c=; 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=VeCKfOYAWkmXQNe9VpcH0V6xaLQmYyt7vxcd5WQbJQg6BhGXxscwrTQmsWsc7Mi3 DaQLJYd16OiBMyV8VRQnVuKfDhBiWf85XJJ5DI9KAX1TVZtgUtOhEVUeMIyM5SIxQ bCpE35jceWU1lCVqQdt8hGz9bA2yCXvDZxLw9fbv81hUHyh31odWOI3njGC3hrxJy SLN80hn8Rov3lulgwv+5OLko3aHllE4krMyga9i92ubbADS8M86jtdDQi8A4DU5vW wS8T8YLUd4XC6VAfrkcqSryqMhm7ygxlJKjccfPf8ItYhUP0gfECQDPm5L5L1NxZ6 KOFFPSRc/G86CIbfgQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([212.95.5.151]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N0oFz-1s0vsC10mz-00y8Vn; Sat, 28 Sep 2024 16:58:25 +0200 Content-Language: en-US In-Reply-To: <86v7yg57u3.fsf@gnu.org> X-Provags-ID: V03:K1:fLfiDZQvWOYxCA66te4xxF61hEenVKQi4/eHcIgnxQt382Rj8UZ oFuJvUqBmUxoH/Sezi+zxhJ7sj00OzjxT/EEsXXCodglFWyBlOvhntIp65lQR0qRxSVsyz5 SgZqDBeWIx8j+1WwoPmYWpmmkdzJrEW2VuR7J0tAaRA608geripbHKsA5iUiTXePGecLLh4 2pBrm4WsrcSHJiUqM/nPQ== UI-OutboundReport: notjunk:1;M01:P0:f5QaU+cPmSw=;0JDpWLWDrz207h1Mzz6dQMflN3a sIJjEhl/uu47GNvaLx6+mUdR/hu+Wwx7m3cvDDTNIJG19eR3bsWRkdw43Cq57DWrADPMRQlfZ 41pdpHOoHGeHYovxgShjk/1m07+9hifSIKMvDhnEeH27RnTIiEZY2yq29rfVmt3p0atP2jUF6 Y+Xvesr1OhZC6s8WF+07DljfH8RwM6Trb6R/BnVK1Up/DyBujykkV4nXxWWrcXtcZ+VT4O7Kd IgMNw1M8ellAFCZVtKfyDiII83bB2nFR4lNo3JmJg+Nqrwy0mFiB0j8iTO1D+qqYeGucig335 WZ+7ON/4OBY65AB0iOA2P62z6IXt3VB42Hmms72xRw8CwlC3T5jUhpTVXI4ZW/MvlrEaxEvFB UW1ofLOQHxQCVlnAzkUSoTs7snLzpdtVUF0e8lVTzsM3aE22pXBrktk1PLkPHg8vMsfUILilh EwXZLmdR3FN8O0HibFIysxcQa8+932qajHiqflQwUlbAtYn37mxxyGYdF/vQIKV+xD+u7Hbwc bLgLPQ7UusIDY2q6wbhWfgTA3L6Ukk9uWDvkXUAJvx0+xk1268MHGvvlIdPm5G+aYqwScZKqV 3pY4NahTKKYA/zoONVfq5YbKIAm6qKeYCdSpyEYi8yG5ftOHaUCEZhU8Z40w45mny7fsmQMZ/ doMDn/ld04D6XY/JZFypt+b5/3jdYIFtC1YqPtaduSiCiKTMjRUeJsv1MOKJwPcf+IQbh5t7Q pVOGiMMZOiU6+KINKf2Ebmbqc/6yX9/Aip7tlhxZwtTfNV5/6uoSvNeNsTvrlQWltAxB7xIO Received-SPF: pass client-ip=212.227.15.15; 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_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_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:324174 Archived-At: > So maybe this is better: > > Dead REFER window was not a leaf window" OK. >> >> + 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". > > Yes, so I suggested replacing "must not be internal" with "must be a > leaf window". Is that wrong? No. We could also say "must display a buffer". > >> >> 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'. > > So this fixes a related but different bug? It wasn't a bug so far because the "old buffer" was not defined for dead windows. 'window-old-buffer' is described as Return the old buffer displayed by WINDOW. WINDOW must be a live window and defaults to the selected one. The return value is the buffer shown in WINDOW at the last time window change functions were run. It is nil if WINDOW was created after that. It is t if WINDOW has been restored from a window configuration after that. What the patch does is to now make it work for dead windows in the sense that its value is that of the buffer shown in the window at the time the window was deleted. In general, this _is_ the buffer stored in the old_buffer slot. But if we manage to delete a window whose old buffer is nil or t _before_ running window change functions on it for the first time, it isn't. But I just noticed that even 'window-old-buffer' can be affected by the patch if we (i) make a window (ii) delete it before it's seen by the change functions and (iii) resurrect it. In that (unlikely) scenario the next change functions will consider the window as one seen by the last change functions although these have never seen it. I have to add another slot del_buffer to the window structure. martin