are there hooks for text becoming visible or hidden in a given window?

are there hooks for text becoming visible or hidden in a given window?

[Thomas Lord]

Dear Emacs Lisp hackers,

Is there a way to mark a region of text in a buffer, so that when that 
text becomes visible in any window, or when it stops being visible, a 
hook is called and provided the location of the text in the buffer, and 
the window in which its visibility has changed?

I would like to implement a feature that when certain text changes 
visibility, the contents of separate buffer are automatically changed.  
For example, if a markdown image link scrolls into view in one buffer, 
the image itself would appear in a second window, but disappear from the 
second window if the link is deleted or scrolled outside of the window.

I couldn't find anything like this and I don't see a clean alternative.  
Watching scroll events would only cover part of the problem and I'm 
worried about the interactive performance of having to frequently search 
the range of visible text for text with a certain property or within a 
certain overlay.

Thanks,
-t

Re: are there hooks for text becoming visible or hidden in a given window?

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Is there a way to mark a region of text in a buffer, so that when that text
> becomes visible in any window, or when it stops being visible, a hook is
> called and provided the location of the text in the buffer, and the window
> in which its visibility has changed?

To detect when a chunk of buffer is visible, you can use jit-lock.
It's not exact (it will sometimes trigger even if the chunk is not
actually visible), but it's probably the closest we have (especially if
you want it to be efficient even where there are thousands of such
buffer-chunks to "monitor").

> but disappear from the second window if the link is deleted or
> scrolled outside of the window.

We don't have anything for that, no.  I'd suggest you use
a post-command-hook that monitors which of those thingies is
still visible.

I have been known to propose the introduction of
a `post-redisplay-function` which would work like
`pre-redispay-function` except it's run after the redisplay.
I think I have a patch for that lying around (IIRC originally written
to try and improve the display of "tofu" by adding a `help-echo`
property to those characters).

I guess you could use such a thing as well (and potentially for both
uses).  Changing a buffer in response to changes to the display of
another window isn't well supported by the redisplay (because it means
you need a redisplay cycle right after a redisplay cycle), so you'd need
to force a new redisplay "by hand".

There might also be some questions about what "visible" means.
E.g. is a chunk of buffer "visible" if it's between `window-start` and
`window-end` but is covered by an `invisible` property?  Or if it's
(horizontally) scrolled out of view?


        Stefan

Re: are there hooks for text becoming visible or hidden in a given window?

[Michael Heerdegen]

Thomas Lord <lord@basiscraft.com> writes:

> I couldn't find anything like this and I don't see a clean
> alternative.

Reminds me of the task I had to solve when implementing "on-screen.el" -
a package that indicates the formerly visible region after scrolling a
window.  What you want is nearly the same: observe the visible region of
a window, do something (involving redisplay) when it changes.

It was surprisingly tricky to do.  I didn't use jit-lock, I used hooks.

Dunno if the solution I implemented is a good one, aesthetically, but it
worked reliably over the years, so that approach is somewhat tested.

Michael.

Re: are there hooks for text becoming visible or hidden in a given window?

[Eli Zaretskii]

> Date: Thu, 24 Feb 2022 14:25:39 -0800
> From: Thomas Lord <lord@basiscraft.com>
> 
> Is there a way to mark a region of text in a buffer, so that when that 
> text becomes visible in any window, or when it stops being visible, a 
> hook is called and provided the location of the text in the buffer, and 
> the window in which its visibility has changed?

Please clarify what you mean by "visible" in this context.  I mean not
a couple of examples, but an exhaustive, complete definition.

> Watching scroll events would only cover part of the problem

Which part it won't cover, in your opinion?

> and I'm worried about the interactive performance of having to
> frequently search the range of visible text for text with a certain
> property or within a certain overlay.

Why do you think this could be expensive?  A typical window doesn't
show too much text.

Re: are there hooks for text becoming visible or hidden in a given window?

[Eli Zaretskii]

> Date: Thu, 24 Feb 2022 19:10:39 -0500
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> I have been known to propose the introduction of
> a `post-redisplay-function` which would work like
> `pre-redispay-function` except it's run after the redisplay.
> I think I have a patch for that lying around (IIRC originally written
> to try and improve the display of "tofu" by adding a `help-echo`
> property to those characters).

How would post-redisplay-function be different from pre-command-hook?

Re: are there hooks for text becoming visible or hidden in a given window?

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> I have been known to propose the introduction of
>> a `post-redisplay-function` which would work like
>> `pre-redispay-function` except it's run after the redisplay.
>> I think I have a patch for that lying around (IIRC originally written
>> to try and improve the display of "tofu" by adding a `help-echo`
>> property to those characters).
> How would post-redisplay-function be different from pre-command-hook?

It would also run after things like inserting text from a process
filter, and would be told which windows had been updated.


        Stefan

Re: are there hooks for text becoming visible or hidden in a given window?

[Thomas Lord]

Thank you to everyone who replied to this.  I found it
very helpful.

One thing I take away from the discussion is that my fear
that the time-cost of scanning the visible text in
a buffer is probably a "hangover" from first starting
to write Emacs Lisp programs in the late 1980s when
things were generally much slower than today.

I also realized, thinking more about my problem domain,
that perfect synchronization of the various windows is
not essential and its even better in the long run to assume
synchronization can lag noticably as long as its not a huge
lag.

That, plus the various hooks identified that will do at least
part of the job give me lots of options to start by brute-forcing
sync. between commands and/or on a periodic timer and then, if
necessary, use the existing hooks to perhaps speed that up a bit.

Thanks!
-t



On 2022-02-24 14:25, Thomas Lord wrote:
> Dear Emacs Lisp hackers,
> 
> Is there a way to mark a region of text in a buffer, so that when that
> text becomes visible in any window, or when it stops being visible, a
> hook is called and provided the location of the text in the buffer,
> and the window in which its visibility has changed?
> 
> I would like to implement a feature that when certain text changes
> visibility, the contents of separate buffer are automatically changed.
>  For example, if a markdown image link scrolls into view in one
> buffer, the image itself would appear in a second window, but
> disappear from the second window if the link is deleted or scrolled
> outside of the window.
> 
> I couldn't find anything like this and I don't see a clean
> alternative.  Watching scroll events would only cover part of the
> problem and I'm worried about the interactive performance of having to
> frequently search the range of visible text for text with a certain
> property or within a certain overlay.
> 
> Thanks,
> -t

Re: are there hooks for text becoming visible or hidden in a given window?

[Emanuel Berg via Users list for the GNU Emacs text editor]

Thomas Lord wrote:

> One thing I take away from the discussion is that my fear
> that the time-cost of scanning the visible text in a buffer
> is probably a "hangover" from first starting to write Emacs
> Lisp programs in the late 1980s when things were generally
> much slower than today.

Just generally? :)

-- 
underground experts united
https://dataswamp.org/~incal