all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: JD Smith <jdtsmith@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: region-based face-remapping
Date: Tue, 9 Jan 2024 15:20:53 -0500	[thread overview]
Message-ID: <D029181B-12CF-41A9-8F6D-E10C9803CC4D@gmail.com> (raw)
In-Reply-To: <jwv8r4ywqj6.fsf-monnier+emacs@gnu.org>



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




  parent reply	other threads:[~2024-01-09 20:20 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08 21:49 region-based face-remapping 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-15 20:17       ` Stefan Monnier via Emacs development discussions.
2024-01-09 20:20     ` JD Smith [this message]
2024-01-10 12:36       ` Eli Zaretskii
2024-01-09 21:31   ` JD Smith
2024-01-10 12:44     ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2024-01-02  0:22 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
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

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=D029181B-12CF-41A9-8F6D-E10C9803CC4D@gmail.com \
    --to=jdtsmith@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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.