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: Tue, 8 Jun 2021 11:11:21 -0700 Message-ID: <62e438b5-d27f-1d3c-69c6-11fe29a76d74@dancol.org> References: <86a85d26-75c0-e4a3-e8d3-244c5346dd3a@dancol.org> <83r1hehnz9.fsf@gnu.org> <83lf7mhl3n.fsf@gnu.org> <73ff18bf-66dc-7d7a-a0db-8edc2cdceba8@gmx.at> <83o8cge4lg.fsf@gnu.org> 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="31883"; 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: rudalics@gmx.at, emacs-devel@gnu.org, rms@gnu.org, acm@muc.de To: Stefan Monnier , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 08 20:14:23 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 1lqgF5-00083M-B3 for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Jun 2021 20:14:23 +0200 Original-Received: from localhost ([::1]:54674 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqgF4-0003Ip-64 for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Jun 2021 14:14:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56700) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqgCQ-0001kC-HH for emacs-devel@gnu.org; Tue, 08 Jun 2021 14:11:39 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:56894) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqgCK-0003mZ-3A; Tue, 08 Jun 2021 14:11:38 -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=/fjLnsBS29lOFNYx91DQr+bEfk/1A+FClliwwRhqR+8=; b=W2RrGnmv1bi7kOGpwFWCuAvKVJ vl/VFaTEtEryG//yEYz67goEToPg8fnjYhPQY59stajRPwciW+Cvo5NqnFpX7EZ0VYrbgEcKbVH7k db6KT75v9Mmk2pq0Joz+sQKXcRl6xOmc40jWN5nybvTST7L3qUboQvGNSuZczUginuaIEtKDjtYLQ 4xl8Qpdn/FigW3XZPS+St3UTmgt+7BbBIcrtYzi01Pb9axR9gctxbaPI/zz6YCJrfkNGDOLtnEN3l wIn6/9JW683Ul75rM5kGY093BbN3DOaiBY6ri3xp6gnq7/1JOmLDnfO1rZESSuJ6AuvNN9DYtnOaq 7Y/T64fg==; Original-Received: from rrcs-173-196-147-115.west.biz.rr.com ([173.196.147.115]:59968 helo=[10.29.6.40]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1lqgCB-0006p7-M1; Tue, 08 Jun 2021 11:11:23 -0700 In-Reply-To: Content-Language: en-US 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, NICE_REPLY_A=-0.001, 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:270580 Archived-At: On 6/8/21 9:36 AM, Stefan Monnier wrote: >>> All I meant is that given the increase of performance of CPUs (until the >>> beginning of this century) and a non-corresponding increase in file size >>> and complexity of language syntax, programmers nowadays prefer correct >>> behavior over fast behavior, since the correct behavior is fast enough >>> anyway to be bearable. >> Not in CC Mode, not IMO anyway. But perhaps you don't consider what >> CC Mode does to be "correct behavior". > My comment was about using hacks like > `open-paren-in-column-0-is-defun-start` to avoid scanning from BOB in > `syntax-ppss/propertize`. > >> And then, of course, there's a question "what is correct"? When I see >> something like >> >> static foo_t __attribute__((bar)) myvar; >> >> I'm not sure I'd care if everything before "myvar" would be in the >> same face and "myvar" in another face. IOW, it isn't necessarily >> important to me that fontification knows that foo_t is a type and not >> a keyword. So searching the file (and perhaps other files) for the >> definition of foo_t isn't important -- for the purposes of >> fontification. > FWIW, my `font-lock-type-face` is customized to: > > '(font-lock-type-face ((t))) > > so I'll let you guess my opinion on this ;-) 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. 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.