emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Final" version of tty child frames


From: Eli Zaretskii
Subject: Re: "Final" version of tty child frames
Date: Fri, 17 Jan 2025 14:26:07 +0200

> Date: Fri, 17 Jan 2025 10:08:35 +0100
> Cc: gerd.moellmann@gmail.com, jared@finder.org, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Did you try this with auto-hscroll-mode, both set to t and to
>  > current-line?  What happens then if you move cursor with C-n and enter
>  > a line which is partially obscured by a child frame?  Or if point
>  > becomes hidden because it enters the obscure part of the frame from
>  > above or below, not from left or from right?
> 
> I now checked these and see no problems.  I see problems when moving
> point in a child frame with truncated lines but this might be a separate
> problem.

Let's hope so.

>  >> +  if (is_tty_selected && glyph->charpos > PT)
>  >> +    {
>  >> +      w->cursor.hpos = -1;
>  >> +      w->cursor.x = -1;
>  >> +    }
>  >
>  > Why do you need this test, and specifically the second part of the
>  > condition?
> 
> It handles the case where the cursor should be hidden because of an
> overlapping child frame.  I may run the loop in step 1 until the end of
> all glyphs when there is an overlapping child frame.  But if I re-enter
> in the combined matrix the part belonging to the underlying frame, I may
> be at some glyph far beyond the glyph that would have covered PT because
> in the combined glyph matrix some glyph of the child frame is at that
> position.  So I have to make the cursor invisible in that case to not
> irritate the user (as I did in a first approximation mentioned earlier).

Since is_tty_selected means the window set_cursor_from_row is called
for is the one from the parent frame (right?), any condition that
looks at glyph->charpos without first verifying the glyph is from that
window's frame must be wrong.  Do you agree?

If the cursor should be hidden because of an overlapping child frame,
how come you didn't detect that when you found the first glyph whose
FRAME is not the window's frame?

Anyway, this is wrong for bidirectional display, where a glyph to the
right of another one could have its charpos smaller.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]