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 13:27:08 -0700 Message-ID: <4bb05195-d29b-c6a5-7cf0-e450dfbc1cac@dancol.org> References: <86a85d26-75c0-e4a3-e8d3-244c5346dd3a@dancol.org> <83r1hehnz9.fsf@gnu.org> <192ccb74-90e5-aebc-1210-c4f685cc3b52@dancol.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="39100"; 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, Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 06 22:30: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 1lpzPV-0009qp-Ii for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Jun 2021 22:30:18 +0200 Original-Received: from localhost ([::1]:33998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpzPT-00088a-GK for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Jun 2021 16:30:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44710) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpzMY-0005v7-DP for emacs-devel@gnu.org; Sun, 06 Jun 2021 16:27:14 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:56888) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpzMW-00022s-8a; Sun, 06 Jun 2021 16:27:14 -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=OjIK5+CAm6T8+sJVJHBbLrpcLVH7rJOmRknJHjaGHuw=; b=REaK9Pv/IQXABD5H1iMxZsETqy 0htRdcCMq/ly2u8H44JwnTenw9mg4dE9uF0vZOR7Gu27wGo7C9bTiJkEWbc+rjz6nSNPAbvD1fd5u U0APfxmweGVOIVz7T8rMVTTq5C9Yvn5XN1pNcgL2BVGkREN+1vpcYPw0cORNLNGleTHCfKuHkXanU RKupEsy8f5FH8HjzI2gYfyDcOrUAg48kMN6M50oB3SEoBPO6DpAPbZMB7xwe8QcUpnkRPLKvifB48 tFvdgtQmMSjnSPYzhzLx2FvJvezKbTiVy14yo+ZNrKuklkJlQAblRR+K30wqZwJ9QItD4f1MC+hHO HoE+SMsg==; Original-Received: from [2604:4080:1321:8020:2761:c5fe:e373:3ed] (port=33366) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1lpzMT-0007SR-FJ; Sun, 06 Jun 2021 13:27:09 -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:270502 Archived-At: On 6/6/21 1:24 PM, Stefan Monnier wrote: >> 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. > [ I assume that what you mean by "fontification" is not literally > placing faces (which is typically what font-lock does), but only > a subset of that job (the subset that needs to proceed sequentially > from BOB). ] > > You mean like what we do for `syntax-ppss` (except we keep the > checkpoint data in an alist indexed by positions, rather than in > text-properties)? Yes, but generic. > > I think it would be fairly easy to add some way to keep extra data in > `syntax-ppss-wide/narrow`. > >> 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). > For `syntax-propertize` we handle this via a `syntax-multiline` text > property, so that changes in the B region cause re-propertization of the > A region. Manually placing syntax-multiline is annoying and error-prone. Can't we instead keep track of what buffer positions were actually inspected?