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: Tue, 08 Jun 2021 11:16:15 -0400 Message-ID: References: <86a85d26-75c0-e4a3-e8d3-244c5346dd3a@dancol.org> <83r1hehnz9.fsf@gnu.org> <83lf7mhl3n.fsf@gnu.org> <73ff18bf-66dc-7d7a-a0db-8edc2cdceba8@gmx.at> <83zgw1g5ie.fsf@gnu.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="20929"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: rudalics@gmx.at, acm@muc.de, dancol@dancol.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 08 17:17:27 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 1lqdTr-0005Ct-6n for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Jun 2021 17:17:27 +0200 Original-Received: from localhost ([::1]:49006 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqdTq-000723-3J for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Jun 2021 11:17:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47126) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqdT0-0005aJ-Oi for emacs-devel@gnu.org; Tue, 08 Jun 2021 11:16:35 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65505) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqdSp-0007fC-84; Tue, 08 Jun 2021 11:16:32 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DECE410028A; Tue, 8 Jun 2021 11:16:18 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8D5FB100040; Tue, 8 Jun 2021 11:16:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1623165376; bh=wFgvef5s7tyrvTaTu1DJ2v2OZ6hWjJ0fIhmw3XC3b3E=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=MtVNXghcuSDe0ac03anm2xzuiR/1ksqpJl5nq43mIjQNkuXvdrePajNCmZrPQaIWp 5bKcMIBMua9uHzDuPjPPL1UApSccMQ+o9lJgCC4Q0o2nmTRvpYs2ln6HpwTN3y1qLR EFur2i0cFTrqbp4Ynv8Jo/1MdcLRXJnqH78sqlYpSYm7dMch7xBQOK8Hy8Yf9r+kXJ h10zrJxyF9MiK8sjsdnPGXBnNPx3PwdD3rNFgd2kjN288C5cuX+aEdMXk7JC5aDa/r mWuAEsaxtvCibEQPTz85OltyNXi4zI1Veny2BPX60QI0RioDoSZXm3onwN291ZkG9C elVCEmjnApiUA== Original-Received: from alfajor (69-196-163-239.dsl.teksavvy.com [69.196.163.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 50AD3120156; Tue, 8 Jun 2021 11:16:16 -0400 (EDT) In-Reply-To: <83zgw1g5ie.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 07 Jun 2021 16:37:29 +0300") 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:270565 Archived-At: >> > Unless `open-paren-in-column-0-is-defun-start' is non-nil. >> We can use hacks like this one, indeed, but it's not in fashion >> nowadays. > Yes, we prefer waiting forever for Emacs to respond to a TAB or RET, I'd be interested to hear about the cases where you think the time to reply to RET or TAB would be sped up by `open-paren-in-column-0-is-defun-start`. The case I know of where it would make a significant difference in practice are things like: - open a large file in a mode that uses a heavy `syntax-propertize-function`, such as perl-mode, and jump to the end. - turn off font-lock-mode, do the same as above (which should be quick this time around), and then hit TAB (at which point you should see the same delay as you saw above). So, yes, there is a performance price to pay, but in return you get simpler ELisp code (because you don't need to implement the hacks), and a more reliable behavior. > and are okay with "random" fontification which triggered this thread. > The price of fashion, I guess. I think you're confused: - the "random" fontification in this thread is in CC-mode, which does not use the approach I described (and used in syntax-propertize). E.g. Alan mentioned that the problematic behavior of CC-mode's highlighting can depend on the order in which the chunks are fontified, and `syntax-propertize` specifically aims to avoid such order-dependency [ And please don't get me wrong: an approach like that of `syntax-propertize` wouldn't solve the problematic fontification, but it would (mis)fonftify the same way every time. ] - it's with `open-paren-in-column-0-is-defun-start` that we had occasional/random misfontification, and it's indeed to get rid of those that we finally changed its default value. The performance cost is real, but AFAIK this cost gives *less random* behavior contrary to what you state. The whole point of the design of `syntax-propertize` is to try and make it eas(y|ier) to get correct&reliable behavior (at the cost of sometimes sub-optimal performance). AFAIK one of the reasons why Alan doesn't want to use an approach like that of syntax-propertize in CC-mode is because his guts tell him that it would be too inefficient for C++. Stefan