From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: cc-mode fontification feels random Date: Sun, 06 Jun 2021 16:24:04 -0400 Message-ID: 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7292"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , acm@muc.de, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 06 22:25:10 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 1lpzKX-0001Zx-KQ for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Jun 2021 22:25:09 +0200 Original-Received: from localhost ([::1]:57984 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpzKV-000552-Oq for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Jun 2021 16:25:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpzJh-0004Px-VR for emacs-devel@gnu.org; Sun, 06 Jun 2021 16:24:18 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11939) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpzJe-0000It-PC; Sun, 06 Jun 2021 16:24:16 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BE2EE80385; Sun, 6 Jun 2021 16:24:10 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 10A978033D; Sun, 6 Jun 2021 16:24:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1623011045; bh=j6l4pzbXr4whZHsLIVYhPBJo/5KhHRKwlP15hQ125jk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=BbR+wv87BHarPAyWQpL3HekWqWQcHvQDJSpPeO7l6U8AIe0ESjUa7wAhpf+WQ8UYz 21fGEoSw1T0gMwYZ7HwSACCebMLkABD0qxgmyimPXp4ff6pzHWQPMykUC8D2h7QWUM yURsN3pObvS4ukXMhqpFghlN8qyOgWHTnE1qqapaQ80AwT0y+SlBt2QKhLdsUunXYC +SmNvikNnehRxD/LTzkbTu1t3QylHMoQMmyge7xwHAWdNdFAKd8bt9W9QK9fCFfXZv bUGaPQSSYPNM0o22vit2n4NCaPT79FIpj+OAgQXPi2qeqxy5fFB8I2DlNDZynWlUtr rU3LfivJA6UBg== Original-Received: from alfajor (69-196-163-239.dsl.teksavvy.com [69.196.163.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C0FBD120376; Sun, 6 Jun 2021 16:24:04 -0400 (EDT) In-Reply-To: <192ccb74-90e5-aebc-1210-c4f685cc3b52@dancol.org> (Daniel Colascione's message of "Sun, 6 Jun 2021 11:33:54 -0700") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:270500 Archived-At: > 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)? 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. > 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. When I wrote the `syntax-ppss` code, I did expect to add facilities to keep extra data in there, but so far the need has not really come up. Stefan