From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pranshu Sharma Newsgroups: gmane.emacs.devel Subject: Re: Add function to rotate/transpose all windows Date: Tue, 12 Nov 2024 00:47:48 +1000 Message-ID: <87ikstsu7f.fsf@gmail.com> References: <87setpdv21.fsf@gmail.com> <87y12iyidd.fsf@gmail.com> <87iktld1bd.fsf@gmail.com> <87r085r2gl.fsf@gmail.com> <87zfms6z1a.fsf@gmail.com> <71571413-02ba-4e3c-ad43-35c110811fab@gmx.at> <875xpfns32.fsf@gmail.com> <0a2f09a0-4115-4421-a391-30d27e7d0821@gmx.at> <87ses9k9wo.fsf@gmail.com> <877c9ersei.fsf@gmail.com> <51068b75-e12d-4161-9a63-8c280e8b2668@gmx.at> <8734k1gnt9.fsf@gmail.com> <8a2007d9-d501-404b-966d-57a7a51310ef@gmx.at> <87ses0r81d.fsf@gmail.com> <69658762-5fc7-4a9d-9262-528dfd9e93cd@gmx.at> <87wmhb2yew.fsf@gmail.com> <801bbd24-8f79-48a4-9615-f5ef21b2341e@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33092"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Juri Linkov , Eli Zaretskii , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 11 16:45:48 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 1tAWbr-0008OL-Cs for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Nov 2024 16:45:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tAWb9-0001q1-Ss; Mon, 11 Nov 2024 10:45:03 -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 1tAVhd-0001qr-Bo for emacs-devel@gnu.org; Mon, 11 Nov 2024 09:47:41 -0500 Original-Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tAVhb-0001eZ-HD; Mon, 11 Nov 2024 09:47:41 -0500 Original-Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-720e94d36c8so4783514b3a.1; Mon, 11 Nov 2024 06:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731336457; x=1731941257; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=h3rSLjqDn+2vYNUIPn1dJOX5sWcroAub5UhoF4oQglA=; b=CAseBT17ttjnVnGMZ2ybvp2+HDp/SDZ+qFJBHtshs6Quhvd2VSkQWTOF2U+Oe2/5Yn HPDBlWbMd7nbHNAVF9LRK1uRnb8ALONxKoCGlmQPfgNSea8gVJMJMYM4fx493YP4CnyY 55aYhDMh6ib/ABQWT8IMMZXI+r6S0U8CnkPr+cYr8tmPeIYaR8Bpo0m9WJXf9R9uib8N 82b4JewSW4BXKSjscvn4xM6fh9SOWJoEUZN42Kb8kg+7F1nsptt4OD0UHsDODa8aRnuj dU2PNmLXX0nbuUP8ldJcAUPoJ3P0oGgCAYdK+5vci0bY61Wa3JJwYgDl/Ay/iOf7jxay mxbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731336457; x=1731941257; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=h3rSLjqDn+2vYNUIPn1dJOX5sWcroAub5UhoF4oQglA=; b=Yu74ij9OLO0XYvTUs/UeaY76EMfuBViIdBCVEqwpK/RsBXfK/29hAJEOj8GOrvl1Lz Tg2XA8G8eNsy5I7pq6nlxZS0Kk64srIODgMj+iWLnCiJSilc1oIdM07ok0+OiPsEUfgh 3innrAf87kqljTFpdYzGqOHx8/3t4CwAi3Sbx7RvgLRV5kFORHUsC6BltThVwZ+tut/f ZJ5SIc0wEq6oKQpVa9dHrhfSUfv2IjUFJ2l6tOdorOLFV7B8bwFFcyJrIBnmXE/7/eub zbLAsbOn3CqQ3Lc7LfSHu1CP7Hg7HQpObH26+URQ29VVZ1ESroI9k3cRHAnXyr61AEkN QgMA== X-Forwarded-Encrypted: i=1; AJvYcCUdSvYexiTVEDuTiq3gFxkeAuDbwtg70BxZV778HhqmKwMEv5JYtVtgRU73jHWTd3RgYJRQEnDe1D8dbpI=@gnu.org, AJvYcCVg3T37LjGdl/MMxbZ/FSE8QhJf9XEutrPfmQKgU3wpqldJjD+frX1Vm4dsDTY0X2FFv1En@gnu.org X-Gm-Message-State: AOJu0YypTzr3vK9hcqh8t5dMRokXsMXqwTxFREUPKRLqfu/7aXpc3l7s YqPl9ij4aiBsqgYFnqLdA4FC0WmHbHCfpaQN2gKmryn00R600GRQx/COyw== X-Google-Smtp-Source: AGHT+IGb9NOtPunh61c70W1O2ugzAAS/RHeXlolKLoBuVhDAEJSQE/oLVaJtv9FKwjV9jTKgDsFwnQ== X-Received: by 2002:a05:6a20:7f97:b0:1d9:a94:feec with SMTP id adf61e73a8af0-1dc232d81afmr19514126637.2.1731336457010; Mon, 11 Nov 2024 06:47:37 -0800 (PST) Original-Received: from pranshu-ThinkPad-E560 ([2001:8003:7816:8300:655:b778:2cf5:13d8]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7f41f5da75csm7338220a12.36.2024.11.11.06.47.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Nov 2024 06:47:36 -0800 (PST) In-Reply-To: <801bbd24-8f79-48a4-9615-f5ef21b2341e@gmx.at> (martin rudalics's message of "Sun, 10 Nov 2024 17:36:36 +0100") Received-SPF: pass client-ip=2607:f8b0:4864:20::430; envelope-from=pranshusharma366@gmail.com; helo=mail-pf1-x430.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 11 Nov 2024 10:45:02 -0500 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:325406 Archived-At: martin rudalics writes: > IIRC I fixed that earlier by binding 'window-combination-limit' > appropriately. I still wasn't able to get it work using that, but what I think will work is `window-combination-resize'. >>> - might fail with atomic windows >> >> What's an atomic window? I read the manual but still couldn't >> understand>> And always keep in mind that once our functions exist, >> people will use >>> them on-the-fly, expecting them to "just work". They won't forgive >>> the >>> smallest misbehavior. >> > > > An atomic window is a parent window - considered the root of the > atomic window - such that all its descendants have the 'window-atom' > parameter set to t. 'split-window' when called with any of these > windows as first argument makes the new window always on a side of the > atomic window. With other words it splits the root instead. Also, > deleting one of these windows deletes the root instead and deleting > all other windows deletes all other windows but the root. > > The idea of an atomic window is that although it is build from > internal and live windows, it behaves like a live window for the > operations mentioned above. It's the smallest unit for them and you > cannot split it just like you cannot split an atom chemically. I see, it's a good idea. Sadly `gnus-use-atomic-windows' does not work when horizontal and vertical splits are mixed, probably going to report this bug later, but as am emacs user and therefore denier of multithreading, I'll wait till this is resolved first. But I got to admit, this was probably not the best name, but then again I can't think of a better name. > I added a 'no-rotate' parameter that can be used for atomic windows so > they do not rotate inside. But I have not tested it well yet. I cannot imagine this going well at all, but I'll test later. >>> - doesn't care about fixed size windows >>> >>> - might fail with small windows. >> >> Highly unlikley, I tried it with very small splits and it worked. > > Note that I've bound 'window-min-width' and 'window-min-height' to > zero. > 'split-window' will automatically choose the nearest admissible size > but > it will fail in a trivial case where you do say a couple of C-x 3 in a > frame that is 80 columns wide but only two lines high. Hopefully the > 'condition-case' will catch them all - precalculating sizes and > rejecting a rotate when they do not fit would be no fun. How about setting a window configuration, then splitting the window, and it goes boom-boom, we can just revert to that? >>> The latter two probably mean that we should run the algorithm with >>> fixed sizes and minimum window sizes in place first. If >>> 'split-window' complains, re-run the algorithm ignoring fixed-size >>> windows and minimum sizes. >> >> What is the expected thing to happen in fixed size windows? > > That they do not change their height, width or both however you rotate > them. If you do say C-h f setq and you have 'temp-buffer-resize-mode' > turned on, Emacs will try to resize the help window and later changes > of > the window structure will usually try to keep the size of the help > window fixed, if that is possible at all. It is simply not possible then to rotate or transpose windows if they are fixed size, imagine a fixed size top level split function, how would that get rotated? I think maybe we can do a map windows at the start to check if any are fixed size, and if yes then we stop. So so far, my game plan is I won't do any of the window alist stuff, rather just the normal window-pixel-tree but include internal windows as well. >> ngl, when you say it like that it sounds like I am making food for a >> kim >> jong ung > > It's more like making a diet plan for him. If I was Kim, I wouldn't mind some extra ice cream at the cost of just another kg