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: Fri, 4 Jun 2021 11:30:09 -0700 Message-ID: <86a85d26-75c0-e4a3-e8d3-244c5346dd3a@dancol.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22050"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 04 20:32:59 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 1lpEcs-0005Sw-VC for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 20:32:59 +0200 Original-Received: from localhost ([::1]:37426 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpEcr-0006Bt-Sx for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Jun 2021 14:32:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44230) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpEaF-0003nh-FO for emacs-devel@gnu.org; Fri, 04 Jun 2021 14:30:15 -0400 Original-Received: from dancol.org ([96.126.100.184]:58020) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpEaC-0005pC-Dw for emacs-devel@gnu.org; Fri, 04 Jun 2021 14:30:15 -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:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject: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=DCEfJcoqqYsLfdEz1CmsDV4Fs/lzxA17h1K1cn2QhSk=; b=LjXzyZvjMLPn26xYOAgoPMF4Xw LZcxWMinTQXOg5quafqs1LcrZI1Zw9cPXYqZqNbC3fIYjaSxqV0vyxOj6kS4CZsgW65nHpQx7047h NjBOMHs3QNvd1Vxql5vXel4IPKVRjDovV57vcEJM+xNNuNPqN+8ADGA8go1pacGUqh7jGCr9ztyhv 5omA5kbIJRAbeZJtRH3Ep5+ialvS82GWxNJs5kEEOpvA0NxAMb0XTG369Ps2qfO1CxDtzIp6Eb/Ym sIj/VXs6yj9ZoIAMI6y/8NhECYttoymeV3sUfPoc4JZ4an/c+F6y0ZtsnRBdXrqCGqbfFGPyyI17E XepDPSbg==; Original-Received: from [172.92.145.124] (port=55564 helo=[192.168.86.213]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1lpEaA-0004XR-4y; Fri, 04 Jun 2021 11:30:10 -0700 In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=96.126.100.184; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 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, NICE_REPLY_A=-0.59, 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:270396 Archived-At: On 6/4/21 8:54 AM, Alan Mackenzie wrote: >> Is there any *general* way that we can make fontification more robust >> and consistent? > Like other people have said on the thread, rewriting CC Mode to use an > LSP parser. > > Less drastically, it would be possible to fix the specific bug you > allude to, by the user making a list of types and configuring CC Mode > with them, rather than attempting to recognise such types. This feels > as though it would be tedious to use, though. I understand that cc-mode can't always get it right. It's only asymptotically omniscient. :-) Some deficiencies in highlighting are bound to happen. What's striking to me is the inconsistency in the highlighting. None of the types in the std::variant declaration in my screenshot is special. They're all declared in the same file as the std::variant typedef. So why is PrimitiveType fontified while the others aren't? FWIW, fontification is correct and consistent when I set font-lock-support-mode to nil, so this really does look like another case of getting unlucky with jit-lock block divisions. Yes, I'm sure that this particular problem is caused by some bug, and with the right repro, we can quickly isolate and fix it. But this kind of seemingly-inexplicable inconsistent highlighting has been happening for years and years now. There's something fundamental about the way cc-mode is written that makes bugs like this keep popping up. Is there some internal abstraction we can add, some algorithmic test suite we can write, that would make this whole class of bug less likely? >> For years and years now, I've been thinking we just need more >> deterministic parser-and-based mode support, and I still think that, but >> on a realistic level, that doesn't seem to be coming any time soon. > What does "parser-and-based" mean? I'd meant to type "parser-and-ast" I think. >> In the meantime, is there any general approach we might be able to use >> to get stuff like the attached to stop happening? > Probably none that we'd like. Fontifying types only at their point of > declaration would be one, but I don't think people would want that. My > impression is that the approach taken by CC Mode, like that of most > language modes in Emacs, has pretty much reached the limits of what's > possible, and it is unreasonable to expect perfect fontification (and > indentation) from languages like C++ in all cases. >