From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: cc-mode fontification feels random Date: Wed, 09 Jun 2021 12:05:27 -0700 Message-ID: <179f22a44d8.2816.cc5b3318d7e9908e2c46732289705cb0@dancol.org> References: <83lf7mhl3n.fsf@gnu.org> <73ff18bf-66dc-7d7a-a0db-8edc2cdceba8@gmx.at> <83o8cge4lg.fsf@gnu.org> <62e438b5-d27f-1d3c-69c6-11fe29a76d74@dancol.org> <83fsxsdxhu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38266"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: AquaMail/1.29.2-1810 (build: 102900008) Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 09 21:09:28 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 1lr3Zv-0009oX-Lp for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Jun 2021 21:09:28 +0200 Original-Received: from localhost ([::1]:60824 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lr3Zu-000684-IW for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Jun 2021 15:09:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37978) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lr3W8-00040V-Vo for emacs-devel@gnu.org; Wed, 09 Jun 2021 15:05:33 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:56900) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lr3W6-0005OL-SU; Wed, 09 Jun 2021 15:05:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=I4GrZFmonWPkBGlQor9b1l/PFqfnMGfZY6UEeaWAWCs=; b=G7BcaPZPwraA9/WH1KfCDrYK0s 0sSpsQpZawm4duZWfd+E+N5XZqC6G5BUh7YtHikY59IPsBlU9DEIMGyuRhmCJr4JTEXt5FFYupplo MVUoyuCrq1gDdQDJQXOUnGScRvMLFxa4Ek6iRZ9tkpE3HFulK74rcr+U+eD4X7rGn59Cj4DswuKi4 Z870hOy5Qp96ScfNLaRhbiPD4ddZdZYB2/75WXgisNwkXqxb89FNziVkjMRk04RY4/Cc7C9IZ4aTk TijFDmf0H7Vq1NzZFjOPU3M/QQOo5B74yLBVtf4e37xgxxlJ9l9/sIfW61PxSiXcRtmMPDYXat+e8 gaYF1Liw==; Original-Received: from rrcs-173-196-147-114.west.biz.rr.com ([173.196.147.114]:39990 helo=[10.29.35.171]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.89) (envelope-from ) id 1lr3W4-0002DA-Kn; Wed, 09 Jun 2021 12:05:28 -0700 In-Reply-To: Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-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:270608 Archived-At: 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. If I can't rely on font lock type face actually distinguishing types from non-types, what's the point? If fontification isn't reliable, it's not syntax highlighting, but instead a kewl rainbow effect. ISTM we can only correctly do fontification of type references with the help of LSP. 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.)