[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: region-based face-remapping
From: |
Eli Zaretskii |
Subject: |
Re: region-based face-remapping |
Date: |
Mon, 08 Jan 2024 19:28:55 +0200 |
> From: JD Smith <jdtsmith@gmail.com>
> Date: Sat, 6 Jan 2024 09:56:08 -0500
> Cc: emacs-devel@gnu.org
>
> I cannot be of more help here without understanding better what kinds
> of application-level features you want to support. Until now, you
> only described that in very general terms.
>
> This is because I was discussing a general feature that would be useful for
> more than my own
> application.
And I'm trying to get a grip on the specific instances of that general
feature which perhaps could be much easier to implement and have much
lower costs.
> To make it more concrete, what I had in mind is an update to indent-bars
> which would changes the
> appearance of the set of bars in a “scope” region via treesitter queries in a
> post-command hook. As
> point changes, the TS “enclosing scope” is calculated, and if it has changed,
> all the existing indent
> bars in that region would be updated with “alternate” styling (and formerly
> highlighted text would be
> returned to normal styling). See [1] for some images to give you the idea of
> how the normal styling
> can look. Important to note are that:
Why cannot this be done by modifying faces or overlays in the affected
region?
Btw, my advice is to use an idle timer, not post-command-hook, if that
is possible. A timer-based implementation will not slow down Emacs
when the user moves point quickly or scrolls through a portion of the
buffer by leaning on an arrow key. Also, the timer will always run
with point corresponding to what is on the screen, whereas
post-command-hook runs before point adjustment, so could use
inaccurate value of point.
> It could be a buffer-local variable, which defines the size of the
> region around point where the faces should change their appearance,
> and how to change the appearance. The display engine then could take
> that into consideration when processing buffer positions around point.
>
> Whether this makes sense depends on the applications you have in mind.
>
> Since there are many small stretches of text (single character stretches)
> that would be impacted over
> a larger region, I’m afraid such a simple approach wouldn’t work.
If all you need is change the faces, I think it will work.
> I understand. The question is whether it would be desirable, tractable,
> performant, and maintainable
> to add any such infrastructure.
I don't know. I do know it will not be simple.
- Re: region-based face-remapping, (continued)
- Re: region-based face-remapping, Dmitry Gutov, 2024/01/05
- Re: region-based face-remapping, JD Smith, 2024/01/03
- Re: region-based face-remapping, Eli Zaretskii, 2024/01/04
- Re: region-based face-remapping, JD Smith, 2024/01/04
- Re: region-based face-remapping, Eli Zaretskii, 2024/01/05
- Re: region-based face-remapping, Dmitry Gutov, 2024/01/05
- Re: region-based face-remapping, JD Smith, 2024/01/06
- Re: region-based face-remapping, JD Smith, 2024/01/06
- Re: region-based face-remapping, Eli Zaretskii, 2024/01/06
- Re: region-based face-remapping, JD Smith, 2024/01/06
- Re: region-based face-remapping,
Eli Zaretskii <=
- 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