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, 30 Nov 2024 11:07:41 +0100 Message-ID: <50ab6c0a-6afb-4727-9094-178668fc4f4e@gmx.at> References: <87setpdv21.fsf@gmail.com> <87bjyfcncu.fsf@gmail.com> <87cyiuefxs.fsf@gmail.com> <878qthewbq.fsf@gmail.com> <8599bc67-b05d-4afc-8e6e-1ba64a30054e@gmx.at> <87frnp2x85.fsf@gmail.com> <823c7cca-63d4-4568-94bc-11f5949d6c5c@gmx.at> <87h683muss.fsf@gmail.com> <02432e6c-6ee2-4c68-9ebb-246f6be88918@gmx.at> <877c8wadke.fsf@gmail.com> <878qt8spp2.fsf@gmail.com> <0ce35c7a-8b28-4905-a6ab-caf50f2fc750@gmx.at> <87mshl2i6h.fsf@gmail.com> <9b460366-f34e-48f6-a680-e7fa5bc7f598@gmx.at> <87bjy03fql.fsf@gmail.com> <356d63bc-818c-428c-b31b-a0eb227b3a8a@gmx.at> <87o720gjst.fsf@gmail.com> <7dfe87a0-b367-47df-86df-f8fd95163fd6@gmx.at> <8734jbz8sb.fsf@gmail.com> 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="27785"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Juri Linkov , Eli Zaretskii , emacs-devel@gnu.org To: Pranshu Sharma Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 30 11:08:35 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 1tHKOx-00073X-AM for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Nov 2024 11:08:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tHKOF-0003B9-Vy; Sat, 30 Nov 2024 05:07:52 -0500 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 1tHKOD-0003Ak-R3 for emacs-devel@gnu.org; Sat, 30 Nov 2024 05:07:50 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tHKOB-0003pN-Tj; Sat, 30 Nov 2024 05:07:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1732961262; x=1733566062; i=rudalics@gmx.at; bh=UwLsyZyRPnIfhLtuwwHXrVegd59ZEhU9NB/Wu1cZAPU=; 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=GdlbNU8zWntyiuWDHDQEWh64Gb/LYWOrLGjZTOzRdE/gwcqurGkWa0AaTScHIPdA 83FKMnKeM/WAefyGIz9aO1IZMROFBhV6OPfCHLzyi51Wq+ydwVb7xYdDvsrIAslDZ 2jRJ88edCNmdiM5CFPYz0h99m+pQs3oZs1zylfGrGw9DES1QcEeNzOwSzXpQbwvMR ZYC8eVQds31Ncl9/4w9wu1NliOIMhaSzKspF1LdhY+Gl0z4nUDa4pmAhgvDeogdQv F6X5YhC9vgEmMAtVpt4zRSU7QIrQFIrSUZE2/3YMKnVbPNnPeVM+A7qmfJhJUeGYF JF2Uva8TatsiGAHXow== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([212.95.5.101]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MwQXN-1ta67n1SQH-012OXf; Sat, 30 Nov 2024 11:07:42 +0100 Content-Language: en-US In-Reply-To: <8734jbz8sb.fsf@gmail.com> X-Provags-ID: V03:K1:jZ1uJbTtSj2f8pKw+vU5NmLobMXxBmfwBlNvf/XSh3MTfsLml/e +qjzw2vYKIR+g0/y20rPSrGTIhDT5dqL265G9JkVJ6isIvjx7lY1zSL3oAFnsVmIKNI9lJy izCWkYhoQ/h7weU2KETaKnCfsIaFx5w1uoMMKY7sD/2nPnYIKAT45nYsknw4pXp0Lok2vfT XrbMIm2UCfoI6B56Ud9mQ== UI-OutboundReport: notjunk:1;M01:P0:DwNSLLBoNvQ=;RMQ2FTpKV88ryIH33Gl8JweQfXM QVWGj/xi2RqLONF6tF2Q+zuFTzvnrU1sZDr/g21MER+EZrJmxOwvA81g/l/5OlZf4W+ICVIMq mhdgFP+NsYLlo2rfTox9gmM0kgJALx066V0vUJ2gN217Hj4yAWTtlKU+1zTzoKLMUjQAiIWH6 JKQJ0xSUlqE4IGsk9ZYcHr7UY9B8mtaLLWIa3xILJG1CaOa72Sw2fyhctAVoqvn3IJSm9p6n0 mVevu500RegVRu0Juy84kljwhXM/LX+hFMiE6sDbIFNKy71E8T3lmlyeqKq8q68rCTUyyWOfX kXh3vrsSoKfI1GqfiQzJ1k4Ag/5azOcZ/T/4VI46XylxMnJ22AMF6/I+Vj48ipj30rqjBV71Z OBfcLyx/ERq3hsyl90+GiIYk1KfmFeHIpEAQChgrVExCx/j6xHAN0B41xGqKsdZFdhV1D3aZw 2P/n3+wn8L64JeY42Q/mMppwsu2cWSEM44IRJw9wlhHo7kY/MZR+WXwSqOLwwGeoEwqeue90G qSwjK/28ZqreAjQijIZ/nXTb7Pbcrg6YWkJruTn2eUMnuWJU+mShx3ONCBtR86so/PuajeGf1 nOPYz63BMstbHwxWOrFDDfR3Ek0bnVfwtM+LQd1LYlBxjkbHXYHMCHGErCbQFOf7Cp9C/6ND7 119mgoSoqhKGPc89fbk0aJAkxKCoj1/UB1lzNrTpmrmL027Ci/rjr7/2iOP+v0vBb9MYAT6Bp zprsJ2avnpob9NKg4d/SMe/eOC41fevInWIJq38vBK/SXrfXrWFUmZWK3hiXyhzGqQof+b7H Received-SPF: pass client-ip=212.227.17.22; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_DNSWL_LOW=-0.7, 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:325871 Archived-At: > Right now, I feel the code is in a pretty complete state. Let's try to polish it up a little so it becomes easier to read. The doc-string of 'window-tree-pixel-sizes' should be updated. Maybe it should be renamed to 'window-tree-normal-sizes' too. Also, the repeated consing somehow obscures the fact that you are constructing a list for each window. So I would write, instead of ((window-top-child window) (cons (cons t window) (cons (cons (window-normal-size window nil) (window-normal-size window t)) (window-tree-pixel-sizes (window-top-child window) t)))) something like ((window-top-child window) (list t window (window-normal-size window nil) (window-normal-size window t) (window-tree-pixel-sizes (window-top-child window) t))) You obviously would have to make sure that my interpretation of your code is correct. In the commands I wonder whether the SUBTREE argument is necessary. Couldn't we simply say that FRAME-OR-WINDOW defaults to the parent of the selected window if it exists and to the selected frame's root window otherwise. In either case, the (window (cond (subtree (window-parent)) ((windowp frame-or-window) frame-or-window) (t (window-main-window frame-or-window))))) should be factored out into a separate function like say 'window--window-to-transpose' with FRAME-OR-WINDOW (and possibly SUBTREE) as arguments here and in the remaining commands. 'deepmap' must be renamed to something like say 'window--deepmap' and needs a doc-string. 'cycle-windows' is still a mystery to me. I think we must first make a clear distinction between windows and the buffers they display here. So far there was no need for that since "window A" meant just the window showing buffer A or the parent window A. That is, we silently assumed some sort of identity mapping between window and buffer names. Now we would have to say something like we start with "window 1" showing "buffer A" and end up with "window 2" showing "buffer A". I yet have no good idea how to do that also because it might affect the description of the remaining commands as well. CONF, DO-NOT-CONVERT-SIZE and ATOM-WINDOWS should IMHO become lexically bound variables. IIUC they are never altered within the body of 'window--transpose-1' and only clutter up the recursions. 'fwin' should become 'first-window' since "f" alone could be taken for "frame". And instead of 'selwin' I'd write 'selected-window'. Also writing 'win' instead of 'window' is hardly ever a "win" in my experience. The comment in ;; All child windows need to be recursively deleted. (delete-other-windows-internal fwin window) is misleading - 'delete-other-windows-internal' usually does not recurse. I think there's no need for a comment here. (mapc 'window-make-atom atom-windows) could be a bit of a problem (it assumes that 'window--atom-check' has done its work in between) but let's leave it alone for the moment. 'n-set' is not explained anywhere. Please give it a more descriptive name. ;; `ilen' is the max size a window could be of given the split type. ;; `flen' is max size the window could be converted to the opposite ;; of the given split type. I think these have become obsolete now. (let* ((d-win win) (is-atom neither of these are explained. Also (_ (while (listp (caaddr d-win)) (setq d-win (caddr d-win))))) is a very uncommon thing to do. Can't you use a lambda here? 'window?' is a very uncommon name, please use something more descriptive. ;; By using cdddr, we ignore window split type, sizes and the ;; first window (it's implicitly created). But what _is_ in the cdddr? ;; (caaddr subtree) is the first window. The "first window" of what? Finally, Richard (Stallman) told me Now they make sense to me -- but the words suggest another meaning, to operate n the contents rather than the window layout. The words that for me fit these meanings are transpose-window-layout and rotate-window-layout. I think he's right and also addresses the ambiguity of 'cycle-windows'. I asked him to post his suggestion on this list but so far he didn't. martin