From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: cc-mode fontification feels random Date: Sun, 6 Jun 2021 11:33:54 -0700 Message-ID: <192ccb74-90e5-aebc-1210-c4f685cc3b52@dancol.org> References: <86a85d26-75c0-e4a3-e8d3-244c5346dd3a@dancol.org> <83r1hehnz9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25949"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Cc: acm@muc.de, emacs-devel@gnu.org To: Stefan Monnier , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 06 20:37:18 2021 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 1lpxe9-0006Vh-EW for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Jun 2021 20:37:18 +0200 Original-Received: from localhost ([::1]:52970 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpxe8-000815-7n for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Jun 2021 14:37:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpxb1-00073C-G9 for emacs-devel@gnu.org; Sun, 06 Jun 2021 14:34:03 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:56886) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpxay-0004lM-Sm; Sun, 06 Jun 2021 14:34:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZCVfJjwN3dIzw7BIt6PNnN1tf5+ZDhEynIcgZqNUdZo=; b=hEtRNL4aMjV6oa4woBweNF9UbP mh1J8CD8eXbAfbgAJyxwX3IOF3/lNOGShIGn+rTa5z+GetAQS1L32oJmjxYLx7/rK7sdaBY1KG3qN Gjjw/ku4wVLQoo7EpUjg2oJcZY6YA3n0C4Nsw1A639HF6ce+O655JTm22DWiQzz9Qf8A1fhc63LMz bN/qZcy2fuMttfogO7sZrpIV15IMkgGxtOn6PodzHOg5xtF3up6mc36O3xerLPqRsXhVM+HKdH0Sd ReWuz4YZ/ELoeELzo7ZzZl3Px+ulW8HLLFnaOlTLj8swkZxP9peb4Qr/Hi+vPOc5i+zdVzzLq9aKN 3v3eAYUg==; Original-Received: from [2604:4080:1321:8020:2761:c5fe:e373:3ed] (port=60530) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1lpxat-0007BS-BK; Sun, 06 Jun 2021 11:33:55 -0700 In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:270495 Archived-At: On 6/6/21 11:18 AM, Stefan Monnier wrote: >> So if the first windowful of a file that's displayed is at EOB, >> fontification must go all the way back to BOB and start scanning >> there, until it comes to the end? > Yup. The way to make it bearable is to make that scan be as simple and > fast as possible. > > Note that `syntax-propertize` and `syntax-ppss` also work this way, so > it's already the case that when we start by displaying EOB we first have > to apply `syntax-propertize` over the whole buffer :-( > > In theory, there are various cases (which depend on the specific > programming language under consideration) where we could avoid such > a scan, but it would introduce a lot of complexity so we don't bother. I've been thinking of a new core facility for helping modes implement this kind of incremental buffer analysis. Basically, it works like this: fontification logically proceeds from bob to eob in fixed-size chunks. After each chunk, we checkpoint the state of the fontification engine in a text property. Whenever we modify the buffer, we invalidate chunks that the modification might have affected and proceed from the last known-valid checkpoint. It's more subtle than it sounds though. First, we need to support lookahead. Fontification of region [A, B) might do lookahead and depend on text in region [B, C). If it does, a modification occurs somewhere between B and C, we need to invalidate the [A, B) chunk. If we put the fontification-by-chunking code in core, we can track (via core magic) a high-water-mark of accessed buffer position for fontification of each chunk. This way, invalidation becomes automatically correct. Second, writing fontification as some kind of callback with explicit checkpoint and restore support is annoying, and nobody's going to do that. If it were possible to write fontification programs as coroutines, we would keep mode fontification routines simply and declarative and automatically do both the chunking and the checkpointing.