From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: pranshusharma366@gmail.com, emacs-devel@gnu.org
Subject: Re: Add function to rotate/transpose all windows
Date: Sat, 28 Sep 2024 11:40:27 +0200 [thread overview]
Message-ID: <1bcc1236-0a12-4988-bb77-4cd38fc95b42@gmx.at> (raw)
In-Reply-To: <86zfns6vjw.fsf@gnu.org>
> Thanks, but does it really make a lot of sense to make this a
> side-effect of splitting a window?
It makes sense because (1) we do not have to make a new window that gets
deleted right away and (2) the geometry of the new window will be
handled by 'split-window' directly and not by some obscure copying
routine (I only later noted that 'resurrect-window' got me warnings
about memcpy combined with offsetof writing beyond the bounds of window
structures).
> (If it makes sense due to
> technical reasons, such as commonality of code of the implementation,
> we could have a common internal subroutine with 2 separate APIs
> exposed to Lisp.)
We can write a separate 'split-window-reuse-existing' function and have
it call a 'split-window-reuse-existing-internal' routine so we don't
compromise the present 'split-window' at all. It's up to you what you
like more.
> Or maybe it _will_ make a lot of sense if you reword the doc string so
> that it explains why what we do with REFER is a variant of splitting a
> window. Something like
>
> Instead of making a new window, this function can reuse an existing
> dead window...
OK.
> Btw, "dead window" is mentioned only once in the ELisp manual, and
> even that in passing, so it is not a very clear terminology, and might
> need clarifications in this case.
The problem is that in Emacs a live window is a window that shows a
buffer. Which implies that internal windows are dead. I once tried to
convince Chong that this terminology is misleading but he didn't allow
me to change it.
>> +If the optional fifth argument REFER is non-nil, it has to denote a
>> +dead, former live window on the same frame as OLD or an arbitrary live
>> +window. ^^^
>
> What is "OLD" here?
It should be WINDOW. OLD is the term used by 'split-window-internal'.
> More generally, I don't think I understand what
> you wanted to say by "or an arbitrary live window".
That's a separate functionality to give users more control of the window
the new window inherits properties from. It's useful when splitting an
internal window and the _new_ window should get its initial buffer and
other properties from any but the frame's selected window.
>> In the first case, REFER will become the new window with
>> +properties like buffer, start and point, decorations and parameters as
>> +to the last time when it was live. In the latter case the new window
>> +will inherit properties like buffer, start and point, decorations and
>> +parameters from REFER.
>
> I suggest to describe each case separately, i.e. split the previous
> sentence ("it has to denote ... or ...") into two, and explain
> separately what happens in each case, instead of complicating with the
> former and the latter. Especially as there are additional cases (nil
> or omitted), which add to the confusion:
I'll try to do that.
>> +If REFER is nil or omitted, then if WINDOW is live, any such properties
>> +are inherited from WINDOW. If, however, WINDOW is an internal window,
>> +the new window will inherit these properties from the window selected on
>> +WINDOW's frame.
>
>> + if (!BUFFERP (r->old_buffer))
>> + error ("Dead reference window was not a live window");
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This seems to imply that the function expects a dead window to be a
> live window(??).
In our misleading terminology a dead window can be either (i) a former
live window or (ii) an internal or former internal window. I have to
exclude (ii) because an internal window should never become a leaf
window and vice-versa.
>> + else if (!BUFFER_LIVE_P (XBUFFER (r->old_buffer)))
>> + error ("Dead reference window's old buffer is dead");
>
> Will users understand what is "old buffer" of a window?
It's the buffer returned by 'window-old-buffer'. I will have to explain
this in more detail.
>> + else if (!EQ (r->frame, frame))
>> + error ("Dead referenec window was on other frame");
> ^^^^^^^^^
> Typo. Also, I'd say "was on a frame other that that of window being
> split" or something like that.
OK.
>> + dead = true;
>> + }
>> + 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". If you (or anyone else)
have any proposals on how to improve the nomenclature in this area, I'll
be all ears.
> More generally, the text of these error messages is not easily
> correlated to the problematic argument, because it neither mentions
> the argument by its exact name, nor mentions the problematic window by
> any other specific reference.
So the error messages should explain in more detail what when wrong.
>> + /* Provisorially set new's buffer to that of the reference window,
> ^^^^^^^^^^^^^
> Did you mean "provisionally"? or maybe "temporarily"?
Both would fit the bill. But this is code that I didn't intend to
submit is part of a completely different changeset where the sizes
of an individual window would be needed to set up the size hints of
frames correctly in set_window_buffer.
>> + /* Set buffer of NEW to buffer of reference window. We have to do it
>> + here so the sizes of NEW are in place. But be sure to do it before
>> + adjusting the frame glyphs - otherwise Emacs may inexplicably loop
>> + forever. */
>
> This should be more explicit what code below adjusts the frame's
> glyphs, because without that this very good comment is less useful
> than it could be.
Again part of that other changeset.
>> 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'.
>> @@ -7720,6 +7795,7 @@ delete_all_child_windows (Lisp_Object window)
>> only, we use this slot to save the buffer for the sake of
>> possible resurrection in Fset_window_configuration. */
>> wset_combination_limit (w, w->contents);
>> + wset_old_buffer (w, w->contents);
>
> And this?
Same explanation. The code for Fdelete_window_internal and
delete_all_child_windows should be refactored so that they would call a
common delete_leaf_window.
Thanks for the careful reading, martin
next prev parent reply other threads:[~2024-09-28 9:40 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
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 [this message]
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=1bcc1236-0a12-4988-bb77-4cd38fc95b42@gmx.at \
--to=rudalics@gmx.at \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=pranshusharma366@gmail.com \
/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).