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: martin rudalics
Subject: Re: "Final" version of tty child frames
Date: Wed, 15 Jan 2025 18:01:52 +0100
User-agent: Mozilla Thunderbird

>> Back to redisplay optimization.
>
> Does this mean you've solved the problem in set_cursor_from_row?
> Because that problem, if it's real, has nothing to do with redisplay
> optimizations.

Turning the table: When I insert a character in the row at hand the
problem doesn't occur.  When I just move point it does occur.  Why?

>> Suppose my cursor is in the underlying
>> frame immediately on the left of the left edge of a child frame.  I now
>> start typing a character and the cursor disappears.  I continue typing
>> and the cursor eventually reappears quite normally on the right of the
>> right edge of the child frame.  IIUC this is cursor movement when buffer
>> text was modified, that is, without redisplay optimization.
>
> There are still redisplay optimizations involved: Emacs doesn't update
> the display except on the single screen line where you insert
> characters.

The cursor is on that single line.

> Or maybe you are talking about a different kind of "optimizations"?
>
>> So couldn't we, as long as there's a visible child frame and the user
>> navigates (moves the cursor) in an underlying frame, inhibit redisplay
>> optimizations and pretend a modification of the underlying frame?
>
> Pretend and do what on display?

Do what Emacs would do when it inserted a character: For example,
atomically move the cursor, insert a character and delete it.

But it's obvious that all this would be overly complicated.  I think now
that the problem should be fixed in set_cursor_from_row using the
following approach:

First special case the approach to tty frames.  On a tty there is only
one cursor in the selected window so we don't have to care about the
cursor in any window but the selected one.  Right?

In set_cursor_from_row in step 1 advance over the border glyphs of a
child frame, over any glyph whose object is a buffer but not the buffer
of the selected window and maybe over any glyph whose object is nil (I
don't know what kind of such glyphs might exist - maybe the
truncation/continuation line glyphs).  Whatever it is, we have to bypass
the

           /* glyph was not inserted by redisplay for internal purposes */
           && !NILP (glyph->object))

check.

If the glyph at point is not an object of the selected window's buffer,
the cursor is not shown (IIUC there is a separate routine for detecting
that but we maybe could do it here right away).  Otherwise show the
cursor as usual.

If step 1 fails, we could try a similar approach in step 2 (stop when a
glyph's object is at PT) but I didn't look into that yet.

martin



reply via email to

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