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: Mon, 21 Oct 2024 15:54:19 +1000 Message-ID: <87ttd6rofo.fsf@gmail.com> References: <87setpdv21.fsf@gmail.com> <87v7yeykr0.fsf@gmail.com> <19ca7821-e034-4ae5-9ff6-570243329d74@gmx.at> <87r09224pe.fsf@gmail.com> <87ikudk62k.fsf@gmail.com> <0d879e95-c37e-416d-b439-daa6384c4f30@gmx.at> <878qv8kws2.fsf@gmail.com> <87ed4xvf60.fsf@gmail.com> <861q0qfnhr.fsf@mail.linkov.net> <878quxdant.fsf@gmail.com> <86zfndi6wh.fsf@mail.linkov.net> <87zfncuqhu.fsf@gmail.com> <86v7y00w68.fsf@mail.linkov.net> <87y12smubh.fsf@gmail.com> <96ea5140-9043-4c1b-97f3-4c534296355e@gmx.at> <87frotqx90.fsf@gmail.com> <87y12iyidd.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33105"; 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 Oct 21 08:42:15 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 1t2m7K-0008SM-14 for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Oct 2024 08:42:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t2m6T-0003d4-Gk; Mon, 21 Oct 2024 02:41:21 -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 1t2lN6-0008FL-EY for emacs-devel@gnu.org; Mon, 21 Oct 2024 01:54:30 -0400 Original-Received: from mail-oi1-x232.google.com ([2607:f8b0:4864:20::232]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t2lN3-0004y4-VJ; Mon, 21 Oct 2024 01:54:27 -0400 Original-Received: by mail-oi1-x232.google.com with SMTP id 5614622812f47-3e604425aa0so976400b6e.0; Sun, 20 Oct 2024 22:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729490064; x=1730094864; 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=ehHBpf0uYIukx4c79ZPTrxE8bap31L1Yf4Fzu70rwo4=; b=RNc9pyEtxzCORVfM2SH8kjcOQ2F3akXc9uxVfTfCEcEgzmnAwLOXTvx0Z3ec6oyI7n 71DrD1ha6gLv9wz/Ze/Fqi74AqDVbp/TS0LqRutvZf6gZjneMgJDeQNDTYPrdYeGKVg9 r6WZykvXV/kuwmf89Y+6/rBIyoN2dlKaqm3Yprhtz0gJ9fOy9RRgsBt7SMH4rbMgvcXl xk5wGLCfCoK0apxxJTRs/oeOna0qsj/KRU6WnAOQDNDryAwMcrTD1kZ6bEyihQ/IwEf5 AmmbXWp/EwQMczsr9AYQfqw+pya0eeNtShYek6F8qY0182xkDvlthOvX5JBhqbg8jVXA 399A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729490064; x=1730094864; 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=ehHBpf0uYIukx4c79ZPTrxE8bap31L1Yf4Fzu70rwo4=; b=ZeYondMkIRTLks2b9nneUZBPAkpi/msgiLOg1HLImIPVuomkp3LmhsitvmKRp/Av03 iSey2Vhnze29Ouc4jafxBAz2YIq7nIYVLlOWsxLbuw+ADFzloxDDnrK23Y6UOM4MBJN7 TXxtKt9RB3t4rBMJoJ89PX734/t922EqCWA2DDDX6Yh9MsGi5XTaVStsBWnv5tkjS2rb HouYYl1nSiik7UoCoupXK9xRhSGkC+1HWJyItGQkJ+G9L/pjIq85jRbm7awR9TyORkNw nN+fWdJgRVL4+Q/J00nYYJ7s38vN1+N8gvPNXZ2xf0z0aX4YBMoRz9CcU14Zmh6l+nns 6tAA== X-Forwarded-Encrypted: i=1; AJvYcCUoBOWNDoF/WB4BBxm4cvUkPNT4iEeXUHHaA74HjvRQCuK9qjPWqS1Flbc/JfXM8wEF0+qwDZSG3x3Gm7Y=@gnu.org, AJvYcCUwDmTm1UIyidm2FRfZ0AS9/vb+apGWhPYbzdmUu4DaleDvKpEL8V2Aket3KI4uCdyMNeUY@gnu.org X-Gm-Message-State: AOJu0YzppjB8Bj+ZAvYiLaayAx19PEuHk9AxH36QcUh6JcKya+6BkTcX pP8+F/QVoGWUvg1CcbHv2XIrrxG+4Sw0OYp2ZNgCoCU8OJ1UkN5FbbVJ80cj X-Google-Smtp-Source: AGHT+IFBt0LyYlYtN+GtjW+v8Xp4Hg9mTGKnpScRY2q9Ubtzx7qWNM072psJCp0ybxWK1WZn19Lo3A== X-Received: by 2002:a05:6808:4444:b0:3e3:97cf:2ecd with SMTP id 5614622812f47-3e602c882f8mr8781445b6e.16.1729490063793; Sun, 20 Oct 2024 22:54:23 -0700 (PDT) Original-Received: from pranshu-ThinkPad-E560 ([2001:8003:7816:8300:64a:7441:6732:62e8]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7eaeabb8400sm2145792a12.63.2024.10.20.22.54.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Oct 2024 22:54:23 -0700 (PDT) In-Reply-To: (martin rudalics's message of "Sun, 20 Oct 2024 19:37:00 +0200") Received-SPF: pass client-ip=2607:f8b0:4864:20::232; envelope-from=pranshusharma366@gmail.com; helo=mail-oi1-x232.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, 21 Oct 2024 02:41:19 -0400 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:324699 Archived-At: martin rudalics writes: >> Or do you mean it automaticlly makes the window-parameters the same?, as >> in I won't have to modify anything? > > It should work automatically in the sense that the parent windows get > reused too. But it doesn't work reliably for a couple of reasons: I compiled an it works > With emacs -Q do > > (let ((window (split-window))) > (set-window-buffer window (get-buffer-create "*foo*")) > (setq window (split-window nil nil t)) > (set-window-buffer window "*Messages*")) > > so you have an arrangement with *scratch* and *Messages* at the top and > *foo* at the bottom. Now rotate windows clockwise with the *Messages* > window selected. Here this first deletes the remaining windows and > starts with *scratch* as the root window's buffer. Now the very first > you ask is to split the *scratch* window with REFER set to the *foo* > window. > > This is a bad idea because *foo* is _not_ *scratch*'s sibling in the > initial configuration - *Messages* is. It can break my approach which > reuses the old parent of REFER which, however, is _not_ the old parent > of the *scratch* window. In the next call to 'split-window' you again > ask to split the *scratch* window but set REFER to the *Messages* window. > All goes miraculously well. Ohh, I finally get what you mean. I thought that for each layout, there is only one possible window tree that will match it. > Repeat the call. Now *foo* with REFER *scratch* reuses the parent of > *scratch*. Next *scratch* with REFER *Messages* reuses the parent of > *Messages*. Probably due to the fact in which order you earlier deleted > windows, this changes the parent windows from (the car of each cons is > the buffer window the cdr the parent window) > > ((# . #) > (# . #) > (# . #)) > > before the call to > > ((# . #) > (# . #) > (# . #)) > > after the call. So the parent windows were interchanged. Looks like a > minor annoyance. But with a more complex layout things fail. Try with > > (let ((window (split-window))) > (set-window-buffer window (get-buffer-create "*foo1*")) > (setq window (split-window nil nil t)) > (set-window-buffer window (get-buffer-create "*foo2*")) > (setq window (split-window window)) > (set-window-buffer window (get-buffer-create "*foo3*"))) > > and repeat the scenario. Here, in the second call, when it tries to > split the window on *foo3* with REFER set to the window of *foo2*, > 'split-window' finds out that the parent of *foo2* has been already > reused and allocates a new parent window. > > I think you have to change two things: > > (1) Instead of > > ;; All child windows need to be recursively deleted. > (mapc (lambda (win) > (when (and (windowp win) > (not (eq win fwin))) > (delete-window win))) > ;; We know for sure that first 2 in the list are not > ;; windows. > (cddr (flatten-list win-tree))) > > use > > (delete-other-windows fwin) > > Your strategy of deleting windows piecemeal destroys the original window > structure in a quite chaotic way. The problem is that it will fail when only acting upon a partial subtree. > (2) Whenever you split a leaf window (like *scratch* in the first > scenario), make sure that REFER gets always set to the window's > 'window-next-sibling' (*Messages* in the first scenario) and never to > some window further up or down in the hierarchy (like *foo* in the first > scenario). Which means that in the first scenario you have two possible > strategies: > > - Split *scratch* first with REFER *Messages* and then its parent with > REFER *foo*. > > - Split *foo* first with REFER *scratch* and then *scratch* with REFER > *Messages*. I see what you mean here, I knew I should done something like this from the start when I had to flatten the window subtree. Seems like this will require a rewrite of the windows--transpose-1 (Yay!), but it should be doable, I have an idea of what I could do. btw, is there a major perfomance/memory footprint of the patches you are adding