Re: "Final" version of tty child frames

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  jared@finder.org,  emacs-devel@gnu.org
>> Date: Wed, 15 Jan 2025 09:58:03 +0100
>> 
>> 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.)
>
> I guess you have in mind the per-buffer flag
> prevent_redisplay_optimizations_p?  In that case, it still does what
> you remember.  

Yes, I think so. When I heard it, it rang a bell :-)

> But I think Martin is talking about a different kind of optimizations.

Probably.