emacs-devel
[Top][All Lists]
Advanced

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

Re: region-based face-remapping


From: JD Smith
Subject: Re: region-based face-remapping
Date: Tue, 9 Jan 2024 15:20:53 -0500


> On Jan 9, 2024, at 9:15 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>> What I’m struggling with is how to do something “like font lock” —
>>> i.e. refontify some potentially substantial fraction of all the faces
>>> in a buffer, not (just) on modifications in an after-change-hook, but
>>> also on point-dependent “region of interest” changes, with a priority
>>> given to the displayed region in the window.  IMO, tree-sitter will
>>> make this kind of idea more common.
> 
> [ Sorry, I missed the beginning of the thread and haven't had time to go
>  and read the previous messages.  ]

No worries, thanks for joining.

> IIUC you're discussing features where the appearance of parts of the
> buffer depends on the position of point.  The main design issue with it
> is what to do when the buffer is displayed in several windows (so there
> are several points).  Depending on this, the implementation strategy may
> need to be very different.

That’s a very good point that I had not considered.  In my case, the selected 
widow would take precedence, and other windows just get what they get.

>>> Aside within aside: it would be great if `timer-activate' included an
>>> optional no-error argument so you don’t have to check if it is on
>>> `timer-list’ twice.  I.e. if a timer is already on timer-list and
>>> `timer-activate’ (with no-error) is called on it, do nothing.
> 
> The `timer.el` API is geared towards creating/destroying timers.
> The other functions (like `timer-activate` and friends) seem to have
> been thought mostly for internal use.
> 
> In order to reuse timer objects the API needs a few changes.
> One of them could be to expose a `timer-active-p`, indeed.
> [ Another would be to merge `timer-activate-when-idle` and
>  `timer-activate` so the caller doesn't need to care which
>  one to call.  ]

I had once heard that constantly allocating and destroying timers (say every 
50ms) is memory inefficient, but that reusing the same timer overcomes this.  
Hence timer-activate instead of constantly run-at-time’ing.  It’s possible 
that’s apocryphal (haven’t tested).




reply via email to

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