emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] master fd8f724: * src/xdisp.c (overlay_arrows_changed_


From: Stefan Monnier
Subject: Re: [Emacs-diffs] master fd8f724: * src/xdisp.c (overlay_arrows_changed_p): Fix last change.
Date: Thu, 02 Mar 2017 00:27:30 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

> In any case, if you expect a buffer shown in a non-selected window to
> be redisplayed just because its overlay-arrow was modified, this never
> worked in Emacs.

Hmm.... I see.  Then I guess I really understand even less about this code
than I thought.

> I think it assumes that at most one buffer changes its overlay-arrows
> between two redisplay cycles.

Given that it was used to:

- cause all windows to be considered for refresh when any overlay-arrow moves
- disable the try_window_id optimisation, i.e. force every window's
  display matrices to be re-rendered.

My impression is that it was specifically designed to handle the case
where an overlay arrow is moved in another window than the currently
selected window.  And I think it does that more or less correctly as
long as none of the vars on the list are made buffer-local (I guess it
would still fail in to refresh things in the corner case where one of
the markers is moved from one buffer to another while keeping the same
numeric position).

> To fix this thoroughly, we probably need to add
> overlay-arrow-position, overlay-arrow-string, and overlay-arrow-bitmap
> to the list of variables at the end of frame.el which trigger
> redisplay of their respective buffers.

But that won't catch the case where those vars aren't modified and
instead, the marker's position is simply modified by `move-marker`.

Another option is to change overlay_arrows_changed_p so that it checks
every var to see if it's been made local to a buffer, and if so, loop
though all buffers to check if it changed in any of them (and save the
last-arrow-position per buffer).

> Changes in overlay-arrows always triggered a thorough redisplay.

That's true for changes to overlay-arrows stored in non-buffer-local
variables, yes.  And it was so thorough that it caused re-rendering of
every single window, regardless if it has/had an overlay-arrow in it.

The intent of my patch was to refine this so only those windows which
have an overlay-arrow that changed gets re-rendered.  I think it does
work correctly *if* none of the vars were made buffer-local.

Maybe instead of getting redisplay to pay closer attention to
overlay-arrow-variable-list so as to catch all the cases, we can replace
this with another mechanism which make the redisplay's job easier.
I can see two such options:
- add some kind of function to register a new marker as being an
  overlay-arrow.  I.e. instead of putting the marker into one of the
  variables in overlay-arrow-variable-list, you'd call that function
  (call it `register-overlay-arrow-marker`).  Then redisplay can keep an
  internal list of "overlay-arrow markers" and overlay_arrows_changed_p
  can loop through that list to see if one of them changed, without
  having to worry about buffer-local variables.
- use overlays instead of markers for overlay-arrows: all
  overlay modification functions already trigger the needed redisplay,
  so we could get rid of overlay_arrows_changed_p altogether.
  The downside is that overlay_arrow_at_row would have to look through
  all the overlays looking for one with the magic property, but assuming
  we keep a constraint like "overlay-arrow overlays must start at the
  beginning of the line where the arrow will be displayed", it should be
  cheap enough (i.e. a single call to something like overlays-at).


        Stefan



reply via email to

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