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 09:35:31 +0200 Message-ID: <83y1ono6rg.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> 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="1932"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, dalal.chinmay.0101@gmail.com, emacs-devel@gnu.org, dimitri@belopopsky.com, luangruo@yahoo.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 24 08:36:50 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 1pVSdO-0000L4-5d for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Feb 2023 08:36:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVScf-000568-Sx; Fri, 24 Feb 2023 02:36:06 -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 1pVScS-00053h-LA for emacs-devel@gnu.org; Fri, 24 Feb 2023 02:35:55 -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 1pVScR-00069r-IA; Fri, 24 Feb 2023 02:35:51 -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=zMfa+dcQovXYZqPNYQDI1opes7hP+w65uj6O+zwlak4=; b=ct9pS4goY0U94/jc615M hOrA2wOBcPoqwYtrUHqQ5lJTuK3y2UuAa7UssR8MWVBQVkHB2mGXp31A1mdEkNVqI6tXcg/H4hPAN ufJuYFQzXsbTJkVWUZBaqhFjlPnoUsVGBv3eIcELvx0D9Dj8Ie2HFy99uO+fCiIpLcZxljuz79+Gh DYqaVN7UkYgPB7CSCB2NAcftkaHABcAKADB1RQr5LBA1M8gkCOSkRSoZILO0CPGdfv53UCND4lzSY FjcfNKtf0CrMmQ4yK4CeBdGU4gWGVlDBUCRstjqhP59hJ01tphDjS5eOVGRnuQEe6S6SFB31dBMO+ cRos1R+JXaQMMA==; 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 1pVSc8-0001Tl-P2; Fri, 24 Feb 2023 02:35:46 -0500 In-Reply-To: (message from Stefan Monnier on Thu, 23 Feb 2023 20:08:41 -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:303740 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii , dalal.chinmay.0101@gmail.com, > emacs-devel@gnu.org, dimitri@belopopsky.com, luangruo@yahoo.com > Date: Thu, 23 Feb 2023 20:08:41 -0500 > > Yes and no: yes, there are already cases where the jit-lock-context > heuristic of refreshing everything *after* a modification is not > sufficient 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). > but as a general rule programming languages are designed for > "forward-only parsing" so it's unusual for a change at POS to affect the > parsing before POS Strictly speaking, this is inaccurate: a change in the middle of a line could very well affect parsing of that entire line, so it in effect affects everything from the beginning of that line (perhaps even more, if that line is a continued line, in the language syntax). But jit-lock is supposed to already account for that, and call the fontification-functions with START set to the beginning of the line, unless I'm misremembering. (You already know all that, but maybe João doesn't.) > > To do this, we use a jit-lock implementation detail, > > jit-lock-context-unfontify-pos, which tells us that the contextual > > fontification has just finished. Not sure how brittle it is, but it > > seems to work reasonably. > > I think it won't work reliably in the case where the "immediate" > jit-lock refresh happens to cover everything until window-end (e.g. we > just inserted chunk of text that ends after window-end). In that case > the jit-lock-context thingy will just mark the rest of the buffer as > "not fresh" but won't call your fontification function at all. > [ And of course, there are also those few rare modes that don't use > jit-lock-context at all. ] jit-lock doesn't use window-end. It can't, really: the results of fontification could affect where the window ends, which is why window-end is only updated when redisplay of a window successfully finishes, which is way after jit-lock did its job. That is why jit-lock calls fontification-functions with END that is arbitrarily computed from START; this is controlled by jit-lock-chunk-size. And a function called via fontification-functions could legitimately decide it fontifies more than just the chunk for which it was called. (Again, you already know all that. I'm writing this to avoid potential misunderstandings and confusion.)