[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).
- Re: region-based face-remapping, (continued)
- Re: region-based face-remapping, Dmitry Gutov, 2024/01/06
- Re: region-based face-remapping, Stefan Monnier, 2024/01/15
- Re: region-based face-remapping, Eli Zaretskii, 2024/01/15
- Re: region-based face-remapping, Eli Zaretskii, 2024/01/15
- Re: region-based face-remapping, Stefan Monnier, 2024/01/15
Re: region-based face-remapping, JD Smith, 2024/01/08
Re: region-based face-remapping, JD Smith, 2024/01/09
Re: region-based face-remapping, Eli Zaretskii, 2024/01/10