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 13:44:06 -0400 Message-ID: References: <86a85d26-75c0-e4a3-e8d3-244c5346dd3a@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="26203"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Daniel Colascione , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 06 19:45:04 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 1lpwpc-0006Ws-98 for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Jun 2021 19:45:04 +0200 Original-Received: from localhost ([::1]:44836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpwpa-0005lg-Gv for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Jun 2021 13:45:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46178) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpwp3-000574-8A for emacs-devel@gnu.org; Sun, 06 Jun 2021 13:44:29 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6593) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpwp0-0007HN-6F for emacs-devel@gnu.org; Sun, 06 Jun 2021 13:44:28 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 95B3C1002FC; Sun, 6 Jun 2021 13:44:23 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C941310019F; Sun, 6 Jun 2021 13:44:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1623001457; bh=KzjXQ7hzcTC7sVgd+BCsx4sjJc2/MZoAgerpaKpBb1o=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Yil5cpdsWXzzc82gPvJDgYZCfxoI1ioit8mTVqsrUh1WCEFFQ1Ggx3fbPj9mN/2cK 7Z8C4MgOUFM81pkst90mkwOykPqOHNVF9e9NFjIXc0yR986s5KJufInLdgsI5iMxxr d+YTqKdOd4EyePUbFrv/7hW2tZMgw4PVJ0qWDTH7Uz68YcZIDKLnWjeSUexUAyPYlP Wpa4S1WlHGdgGoBPR20uQb7mqWK4vK6LsyA39c45q5jxVtUkqrwGTVG2q0ZmJuIi2Y JxW+zsJm8WjulI7WZVzfJlp+o+E19/a2/R7Y2pU1p3SAJOSKL4vz8l2hAzBtSTssxF ovIsfiZoG5GDA== Original-Received: from alfajor (69-196-163-239.dsl.teksavvy.com [69.196.163.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8C7FB120D82; Sun, 6 Jun 2021 13:44:17 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Sun, 6 Jun 2021 11:37:47 +0000") 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:270487 Archived-At: > Because of the order various jit-lock chunks are fontified. If the > chunk which establishes foo as a type is fontified first, subsequent > fontifications of foo will use font-lock-type-face. Otherwise, not. The way this is handled in other modes is to keep a highwater mark of the buffer position up to which the text has been scanned for type definitions and then in the font-lock-keywords you start by scanning the text between this mark and the text that needs to be fontified (and then moving the mark, of course). Of course, this presumes that text later in the buffer can't affect highlighting of earlier text (e.g. a type definition has to come before its first use). And it can have other downsides (e.g. if you already do the scan for highlighting itself, it means you now have to do the scan twice (once to collect and once to highlight), and it also means that if the user jumps to the end of the buffer you'll have to scan the whole buffer before you can start highlighting the last screenful of text). > Maybe an improvement might come from scanning the buffer for occurrences > of foo after foo has been recognised as a type and entered into the CC > Mode table. That way, the lack of fontification on foo would be > temporary, at least provided your Emacs is configured to fontify > non-displayed bits of the buffer in the background (which it is by > default). Not since: commit d0483d25c034c38a8c6f0d718e9780c50e6ba03a Author: David Kastrup Date: Sun Mar 4 08:41:08 2007 +0000 * NEWS (fontification): Mention that the new default for jit-lock-stealth-time is now nil. * jit-lock.el (jit-lock-stealth-time): Change default to nil. Preserve 16 as default value for "seconds" when customizing. diff --git a/lisp/jit-lock.el b/lisp/jit-lock.el --- a/lisp/jit-lock.el +++ b/lisp/jit-lock.el @@ -77,9 +77,9 @@ -(defcustom jit-lock-stealth-time 16 +(defcustom jit-lock-stealth-time nil "*Time in seconds to wait before beginning stealth fontification. Stealth fontification occurs if there is no input within this time. If nil, stealth fontification is never performed. > This might need enhanced support from jit-lock, such as some sort of > signal indicating a buffer has been completly fontified. Indeed, there's no way currently for font-lock to tell jit-lock that it has decided to fontify a particular chunk without being requested to do so (Eli suggests setting the `fontified` property, but this means that all the clients of jit-lock have done their work, so it's only correct to set it from font-lock if you run the other `jit-lock-functions` (or if there are currently no other `jit-lock-functions`)), The closest related functionality is that a jit-lock function (e.g. `font-lock-fontify-region`) can return a value of the form (jit-lock-bounds BEG . END) to indicate the region it actually fontified (which should cover the region they were asked to fontify). Stefan