From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: cc-mode fontification feels random Date: Sat, 19 Jun 2021 15:24:52 +0000 Message-ID: References: <83o8cge4lg.fsf@gnu.org> <62e438b5-d27f-1d3c-69c6-11fe29a76d74@dancol.org> <83fsxsdxhu.fsf@gnu.org> <179f22a44d8.2816.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <179f38c0370.2816.cc5b3318d7e9908e2c46732289705cb0@dancol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22895"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, Eli Zaretskii , emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 19 17:25:44 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 1lucqt-0005mE-Tn for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Jun 2021 17:25:43 +0200 Original-Received: from localhost ([::1]:52694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lucqs-0004O3-VW for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Jun 2021 11:25:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34944) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lucqA-0003bP-1U for emacs-devel@gnu.org; Sat, 19 Jun 2021 11:24:58 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:65108 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lucq7-0006Ck-R7 for emacs-devel@gnu.org; Sat, 19 Jun 2021 11:24:57 -0400 Original-Received: (qmail 63335 invoked by uid 3782); 19 Jun 2021 15:24:53 -0000 Original-Received: from acm.muc.de (p2e5d50ca.dip0.t-ipconnect.de [46.93.80.202]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 19 Jun 2021 17:24:53 +0200 Original-Received: (qmail 7934 invoked by uid 1000); 19 Jun 2021 15:24:52 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:270952 Archived-At: Hello again, Daniel. On Sat, Jun 19, 2021 at 09:25:30 +0000, Alan Mackenzie wrote: > On Wed, Jun 09, 2021 at 19:21:20 -0700, Daniel Colascione wrote: > > On June 9, 2021 1:20:32 PM Alan Mackenzie wrote: > [ .... ] > > > You could instead try to specify which tokens should get > > > font-lock-type-face and which shouldn't, thus giving something > > > concrete to discuss. I think this will be difficult to do well, and > > > may lead to the result which I alluded to above. > > Sure. To be more precise: what I propose is not applying > > font-lock-type-face to symbols when we think that symbol is a type solely > > because it's been entered into cc-mode's table of dynamically discovered > > types for the current buffer. > OK, I'll make a trial implementation of this, controlled by a user option > to switch it on and off. Give me just a little time. Would you please try the following, setting the new user option to nil, and let me know how well it meets expectations. Thanks! diff -r 92a4592886a1 cc-engine.el --- a/cc-engine.el Sun Apr 25 17:26:38 2021 +0000 +++ b/cc-engine.el Sat Jun 19 15:15:37 2021 +0000 @@ -10441,6 +10441,8 @@ ;; There seems no reason to exclude a token from ;; fontification just because it's "a known type that can't ;; be a name or other expression". 2013-09-18. + (or c-fontify-found-types + (not (eq at-type 'found))) ) (let ((c-promote-possible-types t)) (save-excursion diff -r 92a4592886a1 cc-vars.el --- a/cc-vars.el Sun Apr 25 17:26:38 2021 +0000 +++ b/cc-vars.el Sat Jun 19 15:15:37 2021 +0000 @@ -1639,6 +1639,15 @@ :type 'c-extra-types-widget :group 'c) +(defcustom c-fontify-found-types t + "If this variable is non-nil \"found types\" will be fontified as types. +A \"found type\" is a symbol which is identified as a type by its +context in the source code. `c-fontify-found-types' non-nil then +causes the same symbol to be fontified elsewhere as a type even +where its context is ambiguous." + :type 'boolean + :group 'c) + (defcustom c-asymmetry-fontification-flag t "Whether to fontify certain ambiguous constructs by white space asymmetry. -- Alan Mackenzie (Nuremberg, Germany).