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: Wed, 15 Jan 2025 17:29:53 +0200

> 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.  But I think Martin is talking about a different kind of
optimizations.



reply via email to

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