Re: "Final" version of tty child frames

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: rudalics@gmx.at,  jared@finder.org,  emacs-devel@gnu.org
> Date: Thu, 16 Jan 2025 14:41:54 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> We need only a suitable hpos/x though that is in the child frame.
> >> That should make the cursor magic in dispnew.c work that prevents
> >> cursors from "shining through child frames". Don't know what that means
> >> for R2L though.
> >
> > "Suitable" in what way?  What is proposed here is to have an hpos
> > whose relation to charpos is indeterminate.  I'm not sure this will
> > fly.  
> 
> Can't say anything to that. Can you elaborate what the problem might be?
> 
> > AFAIU, we don't even understand well enough how come it fixed the
> > problem, do we?
> 
> We do :-). The magic involved is in combine_updates_for_frame
> 
>   /* If a child is displayed, and the cursor is displayed in another
>      frame, the child might lay above the cursor, so that it appears to
>      "shine through" the child.  Avoid that because it's confusing.  */
>   if (topmost_child)
>     terminal_cursor_magic (root, topmost_child);
> 
> where
> 
> static void
> terminal_cursor_magic (struct frame *root, struct frame *topmost_child)
> {
>   /* By default, prevent the cursor "shining through" child frames.  */
>   if (is_cursor_obscured ())
>     tty_hide_cursor (FRAME_TTY (root));
> 
> and so on, which ultimately looks at w->cursor of the selected frame's
> selected window. So "suitable" position means in this context, that (x,
> y) is inside the child frame's rectangle (top, left, width, height).

That's just how the cursor is hidden.  What I meant was the other
problems Martin described, with moving the cursor:

> In a fix I don't like I've put it on the first character on the right of
> any child frame encountered.  But then the real point position will be
> still hidden under the child frame.  So when you lean on C-f (in a
> non-bidi context), the cursor immediately jumps to that position on the
> right of any child frame but point still has to catch up with that
> situation and only when it does that the cursor will continue moving.
> Disconcerting and ugly.

In general, when w->cursor are all non-negative, the display engine
believes that the cursor position corresponds to point, so violating
that could cause problems elsewhere.  At the very least, this should
be prominently documented, and perhaps also some indication of that
kept around, so that this abnormality could be easily detected if
needed.

IOW, let's not add one more subtle factoid into the display code, it
has enough already.