From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: region-based face-remapping Date: Tue, 09 Jan 2024 09:15:05 -0500 Message-ID: References: <83o7dupskh.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8616"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: JD Smith , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 09 15:15:48 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rNCtP-00023q-UF for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Jan 2024 15:15:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rNCsu-0000zP-2M; Tue, 09 Jan 2024 09:15:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rNCss-0000yc-0U for emacs-devel@gnu.org; Tue, 09 Jan 2024 09:15:14 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rNCsp-0003KK-Px; Tue, 09 Jan 2024 09:15:13 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 17113100068; Tue, 9 Jan 2024 09:15:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704809708; bh=+tuCzI/6ckrk3GeXpQ1V+ekOv8ooK28OcuglDjL+cdg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MOczWfOUOdX7hllBAQXkN9EsJXTrRmK4FEhcEX5V3dVfETuux0JVZiSPj3SDwA4iP GI8ei6r0MFqq7OMKrOdpUBQyicOq+VjwGSqo5t9OEkVpd8YciKndbwON3zXqHJABtO 8Lgr8kFN/iiAl5y0EJ+ECvgCbjcLOhMnJlJCoDUeMgb1aA/ON26/0whD2zGdrOCDWL vlD6KUvwYlnq0WhhEjcBgjSsfokIPo6ZZCGsZOifdCfzbT29pOc01Rs7SoRcFmPctP s9tXCAMpFY7GpTnrj9eggNq7eILvZ9wRwysA0G5K9b3JlVk8fC2pBR3iJu78fdM9e6 qXKKnf5nv420Q== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2297110004C; Tue, 9 Jan 2024 09:15:08 -0500 (EST) Original-Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D9AE7120642; Tue, 9 Jan 2024 09:15:07 -0500 (EST) In-Reply-To: <83o7dupskh.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Jan 2024 15:03:26 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314780 Archived-At: >> What I=E2=80=99m struggling with is how to do something =E2=80=9Clike fo= nt lock=E2=80=9D =E2=80=94 >> 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 =E2=80=9Cregion of interest=E2=80=9D changes, wi= th 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. ] 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. >> Aside within aside: it would be great if `timer-activate' included an >> optional no-error argument so you don=E2=80=99t have to check if it is on >> `timer-list=E2=80=99 twice. I.e. if a timer is already on timer-list and >> `timer-activate=E2=80=99 (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. ] Stefan