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: Wed, 9 Jun 2021 20:20:26 +0000 Message-ID: References: <73ff18bf-66dc-7d7a-a0db-8edc2cdceba8@gmx.at> <83o8cge4lg.fsf@gnu.org> <62e438b5-d27f-1d3c-69c6-11fe29a76d74@dancol.org> <83fsxsdxhu.fsf@gnu.org> <179f22a44d8.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="32755"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, Eli Zaretskii , monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 09 22:21:24 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 1lr4hY-0008Of-79 for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Jun 2021 22:21:24 +0200 Original-Received: from localhost ([::1]:36890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lr4hV-0008AV-W0 for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Jun 2021 16:21:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49854) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lr4gj-0006fl-B3 for emacs-devel@gnu.org; Wed, 09 Jun 2021 16:20:33 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:52389 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lr4gf-00041M-Ul for emacs-devel@gnu.org; Wed, 09 Jun 2021 16:20:33 -0400 Original-Received: (qmail 24708 invoked by uid 3782); 9 Jun 2021 20:20:27 -0000 Original-Received: from acm.muc.de (p4fe15b16.dip0.t-ipconnect.de [79.225.91.22]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 09 Jun 2021 22:20:27 +0200 Original-Received: (qmail 8045 invoked by uid 1000); 9 Jun 2021 20:20:26 -0000 Content-Disposition: inline In-Reply-To: <179f22a44d8.2816.cc5b3318d7e9908e2c46732289705cb0@dancol.org> 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:270612 Archived-At: Hello, Daniel. On Wed, Jun 09, 2021 at 12:05:27 -0700, Daniel Colascione wrote: > On June 9, 2021 11:23:04 AM Alan Mackenzie wrote: > > Hello, Eli. > > On Tue, Jun 08, 2021 at 21:25:49 +0300, Eli Zaretskii wrote: > >>> From: Daniel Colascione > >>> Date: Tue, 8 Jun 2021 11:11:21 -0700 > >>> Cc: rudalics@gmx.at, emacs-devel@gnu.org, rms@gnu.org, acm@muc.de > >>> The whole point of fontification is to provide visual hints about > >>> the semantic structure of source code. If cc-mode can't do that > >>> reliably, my preference would be for it to not do it at all. > >>> Fontification of a type-using expression shouldn't change if I move > >>> the definition of that type from one file to another. > >> I think we agree. Except that for me, it should also not try if it > >> cannot do it quickly enough, not only reliably enough. > > Quickly and reliably enough are desirable things, but in competition > > with eachother. Reliably enough is a lot easier to measure, quickly > > enough depends on the machine, the degree of optimisation, and above > > all, the user's expectations. > >>> IMHO, we should rely on LSP to figure out what symbols are types, and if > >>> a LSP isn't available, we shouldn't try to guess. > > "Shouldn't try to guess" means taking a great deal of > > font-lock-type-faces out of CC Mode. I don't honestly think the end > > result would be any better than what we have at the moment. > I think it would be better in fact. The whole point of fontification is to > provide visual clues about the function of a word in a buffer. That's one of the points. Another point is to provide colour, thus giving the eye some pattern to orient around. I think its most important function is to point out comments, thus making things like if (foo) bar (); /* comment about bar else baz (); /* comment about baz */ undangerous. For that case, fine distinctions about types are irrelevant. > If I can't rely on font lock type face actually distinguishing types > from non-types, what's the point? Because the information about types, though imperfect, is nevertheless highly useful. > If fontification isn't reliable, it's not syntax highlighting, but > instead a kewl rainbow effect. Now you seem to be saying that either font lock has to be 100% right, or it's wholly useless. Is that a fair summary of your position? If so, do you disable font lock mode for CC Mode and other modes which can't guarantee perfect font locking? > ISTM we can only correctly do fontification of type references with the > help of LSP. I don't think it would be sensible to try to do it otherwise. > Without LSP support, I'd rather we not try to get it right, sometimes > get it wrong, and make font-lock-type-face unreliable. (We can > correctly fontify declarations and definitions I think.) That's a rather negative way of putting things, which is a bit indefinite and wishy-washy. 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. -- Alan Mackenzie (Nuremberg, Germany).