From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: region-based face-remapping Date: Mon, 08 Jan 2024 19:28:55 +0200 Message-ID: <83zfxfpwdk.fsf@gnu.org> References: <83y1d7zy8s.fsf@gnu.org> <3592E8C5-35FF-44FF-88ED-B458303BF15A@gmail.com> <83edeyzjgp.fsf@gnu.org> <83cyuhy483.fsf@gnu.org> <837ckow5st.fsf@gnu.org> <8B06B532-A445-43AE-883D-C9E5CF5DB870@gmail.com> <83sf3asfk7.fsf@gnu.org> <601BD647-8D40-4000-92F2-E872EFFF40B3@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36260"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: JD Smith Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 08 18:29:31 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 1rMtRL-0009Ea-Ez for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Jan 2024 18:29:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rMtQt-0001z4-8S; Mon, 08 Jan 2024 12:29:03 -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 1rMtQr-0001xx-2P for emacs-devel@gnu.org; Mon, 08 Jan 2024 12:29:01 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rMtQq-0006DB-P2; Mon, 08 Jan 2024 12:29:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=cWuKJzBX7Fui/cv+C8pz5K0loC3XmMNtUcIbkh5HWVo=; b=I9KCZ2LspB/0xMcFgjAb As0EGzf/WRrs7du/LSxk+9WO8/hvjC+oLhRFYWSPew6ZLz7CRsO0zyAA5iXsSCVsuoe2ePffQFZP0 Ox1FTUoASYGJopHMnL/IM7YZteWToZNxYnt51CZRu8bOclSC/Wl7rvGJVVI6x5t33+Si6iZPuq+Ib sHvXYIfQ/xkbCf0PK3/bDT+CQDwzHaJof5Gp94kAIMmpBnZsPJKej5bxAPYH/geZUmrH22OFMDWiQ fNPjMk1SGt5+Tp6dbbbk8wuuhhFmCIKIVcIvT03vJODD6EbwZr0RPoWEKFVzsIJwK8WYqMDSPRcQJ 3xTJhHPjmyhJNg==; In-Reply-To: <601BD647-8D40-4000-92F2-E872EFFF40B3@gmail.com> (message from JD Smith on Sat, 6 Jan 2024 09:56:08 -0500) 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:314756 Archived-At: > From: JD Smith > 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.