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: Eglot "inlay hints" landed Date: Fri, 24 Feb 2023 13:33:09 +0200 Message-ID: <83o7pjnvre.fsf@gnu.org> References: <87356xv65z.fsf_-_@gmail.com> <83fsawriye.fsf@gnu.org> <835ybsr6aa.fsf@gnu.org> <83356wr224.fsf@gnu.org> <87bklktu89.fsf@gmail.com> <83y1oophd0.fsf@gnu.org> <83k008pah3.fsf@gnu.org> <83y1ono6rg.fsf@gnu.org> 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="32349"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, dalal.chinmay.0101@gmail.com, emacs-devel@gnu.org, dimitri@belopopsky.com, luangruo@yahoo.com To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 24 12:33:57 2023 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 1pVWKq-00085e-0B for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Feb 2023 12:33:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVWKB-000262-Se; Fri, 24 Feb 2023 06:33:15 -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 1pVWK9-000250-CB for emacs-devel@gnu.org; Fri, 24 Feb 2023 06:33:14 -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 1pVWK8-0007TY-DV; Fri, 24 Feb 2023 06:33:12 -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=2K68S8vC1jU+fNo7g2jetNemFqrmfbVl/sDx5ErAihA=; b=CvqSJIe1r7pHKqSIVlIU Yg8UCrfThzMzzBCvPtYCwdrjzVnZNe0ZhxQ/xt7YA/431R7A3tND05Gw8AeNcAAYLWfiTO0wbgNkr pDyZ2fgaYcCKsphwhfgWQTIPhNvBt2/obsBUiQSA+Eq+BIrIX37Gn426/pZag4R+f84/5bJ1rJfew hkeI/hZqNDrwIwEWlGeH81vja9eY8nCh0qGtykSbXUwF4h7KwAuqsWKcfCbTeECi9n+APS4JzNltn QhRmun4mAp1BYFKJQUodUsPIcnmTYeCI/y5SjicP4ZeD8X8BFOdKpoA8L+JWbwbOvNEbrx3g6DS4r W7/skDi8UYKZLg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVWK5-0000fd-Od; Fri, 24 Feb 2023 06:33:11 -0500 In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 24 Feb 2023 10:42:26 +0000) 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:303748 Archived-At: > From: João Távora > Date: Fri, 24 Feb 2023 10:42:26 +0000 > Cc: Stefan Monnier , dalal.chinmay.0101@gmail.com, > emacs-devel@gnu.org, dimitri@belopopsky.com, luangruo@yahoo.com > > On Fri, Feb 24, 2023 at 7:35 AM Eli Zaretskii wrote: > > > > If a jit-lock client is smart enough, it should itself install an > > after-change function to remove the 'fontified property from the > > portions of buffer text affected by a change that are before the first > > changed position (or maybe even in other buffers). > > Thanks, I was going to ask about that. I suppose this is how one > marks sections of a buffer "dirty" or invalidatest them so that > jit-lock knows it must run over them again when it sees fit. > > If it works with other buffers as well, it might provide an > elegant solution to the "A affects B" scenario we discussed > earlier. I don't see why it wouldn't work. jit-lock relies on the 'fontified' property to know which part(s) of buffer text need (re-)fontification when they are about to be shown on display. So any portion of buffer text where this property is nil will cause jit-lock to call fontification-functions on that part.