all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: JD Smith <jdtsmith@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: region-based face-remapping
Date: Mon, 08 Jan 2024 19:28:55 +0200	[thread overview]
Message-ID: <83zfxfpwdk.fsf@gnu.org> (raw)
In-Reply-To: <601BD647-8D40-4000-92F2-E872EFFF40B3@gmail.com> (message from JD Smith on Sat, 6 Jan 2024 09:56:08 -0500)

> 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.



  reply	other threads:[~2024-01-08 17:28 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-02  0:22 region-based face-remapping JD Smith
2024-01-02 13:00 ` Eli Zaretskii
2024-01-02 15:49   ` JD Smith
2024-01-03 12:31     ` Eli Zaretskii
2024-01-03 12:40       ` Dmitry Gutov
2024-01-03 13:42         ` Eli Zaretskii
2024-01-04  0:07           ` Dmitry Gutov
2024-01-04  7:05             ` Eli Zaretskii
2024-01-05  3:49               ` Dmitry Gutov
2024-01-05  8:50                 ` Eli Zaretskii
2024-01-05 14:18                   ` Dmitry Gutov
2024-01-05 14:34                     ` Eli Zaretskii
2024-01-05 16:25                       ` Dmitry Gutov
2024-01-03 23:15       ` JD Smith
2024-01-04  6:58         ` Eli Zaretskii
2024-01-05  0:51           ` JD Smith
2024-01-05  8:19             ` Eli Zaretskii
2024-01-05 16:35               ` Dmitry Gutov
2024-01-06 14:04                 ` JD Smith
2024-01-06 13:53               ` JD Smith
2024-01-06 14:27                 ` Eli Zaretskii
2024-01-06 14:56                   ` JD Smith
2024-01-08 17:28                     ` Eli Zaretskii [this message]
2024-01-07  3:41                 ` Dmitry Gutov
2024-01-15 19:55     ` Stefan Monnier via Emacs development discussions.
2024-01-15 20:19       ` Eli Zaretskii
2024-01-15 20:25         ` Eli Zaretskii
2024-01-15 20:36         ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2024-01-08 21:49 JD Smith
2024-01-09 13:03 ` Eli Zaretskii
2024-01-09 14:15   ` Stefan Monnier
2024-01-09 20:20     ` JD Smith
2024-01-10 12:36       ` Eli Zaretskii
2024-01-09 20:20     ` JD Smith
2024-01-15 20:17       ` Stefan Monnier via Emacs development discussions.
2024-01-09 21:31   ` JD Smith
2024-01-10 12:44     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zfxfpwdk.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jdtsmith@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.