Re: "Final" version of tty child frames

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> Let me just quickly add something that came to my mind, namely that one
>> could tackle the problem in two different ways:
>
> Back to redisplay optimization.  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.
>
> 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?

We could try. Back in my days, i-r-o did something slightly different
wrt optimizations, but maybe it's sufficient. (It kind of forced using
try_window instead of try_window_id for example.)

> As a rule, navigating in the invisible area beneath a child frame
> shouldn't be a very frequent operation and maybe we could enhance
> performance by finding some heuristics detecting whether the cursor is
> anywhere "near" a child frame.

We have glyph::frame (only on ttys), which should be equal to the frame
from where the glyphs stems, except maybe for things like vertical
border between windows but that's probably irrelevant for the cursor.
Don't know at the moment how to use that, though.