From: Pranshu Sharma <pranshusharma366@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: Juri Linkov <juri@linkov.net>, Eli Zaretskii <eliz@gnu.org>,
emacs-devel@gnu.org
Subject: Re: Add function to rotate/transpose all windows
Date: Mon, 21 Oct 2024 15:54:19 +1000 [thread overview]
Message-ID: <87ttd6rofo.fsf@gmail.com> (raw)
In-Reply-To: <b83ceec9-7f48-4774-86ea-7f2c91e142b8@gmx.at> (martin rudalics's message of "Sun, 20 Oct 2024 19:37:00 +0200")
martin rudalics <rudalics@gmx.at> 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)
>
> ((#<window 9 on *Messages*> . #<window 8>)
> (#<window 7 on *foo*> . #<window 6>)
> (#<window 3 on *scratch*> . #<window 8>))
>
> before the call to
>
> ((#<window 9 on *Messages*> . #<window 6>)
> (#<window 7 on *foo*> . #<window 8>)
> (#<window 3 on *scratch*> . #<window 6>))
>
> 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
next prev parent reply other threads:[~2024-10-21 5:54 UTC|newest]
Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-24 13:45 Add function to rotate/transpose all windows pranshu sharma
2024-09-24 13:53 ` Eli Zaretskii
2024-09-25 8:05 ` martin rudalics
2024-09-25 8:34 ` pranshu sharma
2024-09-25 9:31 ` martin rudalics
2024-09-25 10:50 ` pranshu sharma
2024-09-25 13:53 ` martin rudalics
2024-09-25 15:31 ` pranshu sharma
2024-09-26 14:10 ` martin rudalics
2024-09-26 14:22 ` Eli Zaretskii
2024-09-27 17:29 ` martin rudalics
2024-09-28 7:52 ` pranshu sharma
2024-09-28 9:26 ` martin rudalics
2024-09-28 10:53 ` pranshu sharma
2024-09-28 14:48 ` martin rudalics
2024-09-29 7:36 ` pranshu sharma
2024-09-29 8:40 ` martin rudalics
2024-09-29 9:23 ` pranshu sharma
2024-09-29 14:48 ` martin rudalics
2024-09-30 6:29 ` pranshu sharma
2024-09-30 8:57 ` martin rudalics
2024-10-01 9:17 ` pranshu sharma
2024-10-02 9:04 ` martin rudalics
2024-10-03 7:06 ` pranshu sharma
2024-10-03 8:17 ` martin rudalics
2024-10-03 10:09 ` pranshu sharma
2024-10-03 14:18 ` martin rudalics
2024-10-04 5:50 ` pranshu sharma
2024-10-04 8:08 ` martin rudalics
2024-10-04 15:10 ` pranshu sharma
2024-10-05 14:43 ` martin rudalics
2024-10-06 2:54 ` pranshu sharma
2024-10-06 15:02 ` martin rudalics
2024-10-06 15:52 ` pranshu sharma
2024-10-07 8:33 ` martin rudalics
2024-10-07 9:42 ` pranshu sharma
2024-10-03 15:12 ` Eli Zaretskii
2024-10-08 18:35 ` Juri Linkov
2024-10-09 6:59 ` pranshu sharma
2024-10-09 16:21 ` Juri Linkov
2024-10-10 11:49 ` pranshu sharma
2024-10-10 16:57 ` Juri Linkov
2024-10-13 5:43 ` pranshu sharma
2024-10-13 8:17 ` martin rudalics
2024-10-14 17:36 ` Juri Linkov
2024-10-15 8:34 ` pranshu sharma
2024-10-15 16:16 ` Juri Linkov
2024-10-18 14:52 ` pranshu sharma
2024-10-18 17:48 ` martin rudalics
2024-10-18 18:37 ` Eli Zaretskii
2024-10-19 1:45 ` pranshu sharma
2024-10-19 6:45 ` Eli Zaretskii
2024-10-19 18:19 ` Juri Linkov
2024-10-19 8:33 ` martin rudalics
2024-10-20 8:19 ` martin rudalics
2024-10-20 14:11 ` Pranshu Sharma
2024-10-20 17:37 ` martin rudalics
2024-10-21 5:54 ` Pranshu Sharma [this message]
2024-10-21 8:14 ` martin rudalics
2024-10-21 9:23 ` martin rudalics
2024-10-21 13:37 ` Pranshu Sharma
2024-10-22 18:12 ` martin rudalics
2024-10-24 14:38 ` Pranshu Sharma
2024-10-24 18:39 ` martin rudalics
2024-10-25 14:24 ` Pranshu Sharma
2024-10-25 17:09 ` martin rudalics
2024-10-26 9:14 ` Pranshu Sharma
2024-10-27 8:23 ` martin rudalics
2024-11-02 14:06 ` Pranshu Sharma
2024-11-05 18:01 ` martin rudalics
2024-11-08 9:23 ` Pranshu Sharma
2024-11-08 10:06 ` Pranshu Sharma
2024-11-08 15:52 ` martin rudalics
2024-11-09 2:14 ` Pranshu Sharma
2024-11-09 8:48 ` martin rudalics
2024-11-08 15:52 ` martin rudalics
2024-11-09 2:09 ` Pranshu Sharma
2024-11-09 8:48 ` martin rudalics
2024-11-09 10:55 ` Pranshu Sharma
2024-11-09 18:06 ` martin rudalics
2024-11-10 10:09 ` Pranshu Sharma
2024-11-10 16:36 ` martin rudalics
2024-11-11 14:47 ` Pranshu Sharma
2024-11-11 16:55 ` martin rudalics
2024-11-12 13:50 ` Pranshu Sharma
2024-11-12 17:46 ` martin rudalics
2024-11-16 13:36 ` Pranshu Sharma
2024-11-16 16:54 ` martin rudalics
2024-11-17 2:45 ` Pranshu Sharma
2024-11-17 10:22 ` martin rudalics
2024-11-17 15:03 ` Pranshu Sharma
2024-11-17 16:38 ` martin rudalics
2024-11-18 0:37 ` Pranshu Sharma
2024-11-18 8:55 ` martin rudalics
2024-11-19 9:34 ` Pranshu Sharma
2024-11-19 17:48 ` martin rudalics
2024-11-21 14:04 ` Pranshu Sharma
2024-11-21 17:54 ` martin rudalics
2024-11-24 13:53 ` Pranshu Sharma
2024-11-26 9:49 ` martin rudalics
2024-11-26 14:14 ` Pranshu Sharma
2024-11-27 8:29 ` Pranshu Sharma
2024-11-27 9:18 ` martin rudalics
2024-11-27 14:37 ` Pranshu Sharma
2024-11-27 17:42 ` martin rudalics
2024-11-28 2:43 ` Pranshu Sharma
2024-11-28 9:28 ` martin rudalics
2024-11-28 15:18 ` Pranshu Sharma
2024-11-30 10:07 ` martin rudalics
2024-11-30 17:41 ` Juri Linkov
2024-11-30 19:01 ` martin rudalics
2024-12-01 4:13 ` Pranshu Sharma
2024-12-03 7:30 ` Juri Linkov
2024-12-03 8:25 ` martin rudalics
2024-12-01 6:41 ` Pranshu Sharma
2024-12-01 17:20 ` martin rudalics
2024-12-02 8:06 ` Pranshu Sharma
2024-12-03 8:23 ` martin rudalics
2024-12-04 15:20 ` Pranshu Sharma
2024-12-04 17:56 ` martin rudalics
2024-12-04 19:12 ` Juri Linkov
2024-12-05 14:16 ` Pranshu Sharma
2024-12-05 17:48 ` Juri Linkov
2024-12-06 4:51 ` Pranshu Sharma
2024-12-06 7:29 ` Juri Linkov
2024-12-05 14:23 ` Pranshu Sharma
2024-12-05 15:17 ` Pranshu Sharma
2024-10-14 17:32 ` Juri Linkov
2024-09-28 7:58 ` pranshu sharma
2024-09-28 8:18 ` Eli Zaretskii
2024-09-28 9:40 ` martin rudalics
2024-09-28 11:35 ` Eli Zaretskii
2024-09-28 14:58 ` martin rudalics
2024-09-28 15:28 ` Eli Zaretskii
2024-10-07 8:33 ` martin rudalics
2024-09-28 13:22 ` pranshu sharma
2024-09-28 14:21 ` Eli Zaretskii
2024-09-28 14:49 ` martin rudalics
2024-09-27 10:06 ` pranshu sharma
2024-09-27 17:29 ` martin rudalics
2024-09-24 17:40 ` Petteri Hintsanen
2024-09-24 19:34 ` Charles Choi
2024-09-25 2:00 ` Emanuel Berg
2024-09-25 7:00 ` pranshu sharma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ttd6rofo.fsf@gmail.com \
--to=pranshusharma366@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=juri@linkov.net \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).