From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: emacs-tree-sitter and Emacs Date: Fri, 03 Apr 2020 09:05:34 -0800 Message-ID: <86lfncfqjl.fsf@stephe-leake.org> References: <83eeta3sa0.fsf@gnu.org> <86369ojbig.fsf@stephe-leake.org> <83lfnfz6jr.fsf@gnu.org> <864ku3htmb.fsf@stephe-leake.org> <83v9mix9vk.fsf@gnu.org> <86a73tgwo7.fsf@stephe-leake.org> <83369lxbwn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="114774"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (windows-nt) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 03 19:06:17 2020 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 1jKPlp-000Tlq-E9 for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 19:06:17 +0200 Original-Received: from localhost ([::1]:58518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKPlo-00010E-Gl for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 13:06:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43030) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKPlI-0000ZR-4C for emacs-devel@gnu.org; Fri, 03 Apr 2020 13:05:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jKPlG-0008Rp-Ji for emacs-devel@gnu.org; Fri, 03 Apr 2020 13:05:43 -0400 Original-Received: from gateway23.websitewelcome.com ([192.185.50.108]:24223) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jKPlG-0008RB-AE for emacs-devel@gnu.org; Fri, 03 Apr 2020 13:05:42 -0400 Original-Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway23.websitewelcome.com (Postfix) with ESMTP id D5B9C1A4EE for ; Fri, 3 Apr 2020 12:05:40 -0500 (CDT) Original-Received: from host2007.hostmonster.com ([67.20.76.71]) by cmsmtp with SMTP id KPlEjl1WEXVkQKPlEjzTQM; Fri, 03 Apr 2020 12:05:40 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=stephe-leake.org; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:To:From:Sender:Reply-To:Cc: Content-Transfer-Encoding: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=F14wqEzYk+iFPIiFloB4NfV9ql7JpTsV6X7wLad449s=; b=kex49igkVyf2EWQYFmrBV08bQ H9Dcv83fqZbkzwBbPzsjWUg9c8M1W10VVIK0GdFEId+wqQKD+J60dbCgstToGWwG9YLtZMz1MB9zV XQmc8T1HSjI9qUNJqdvAE5vSi4xGCaDn6NhC3CDi/c53Mv+btNXe9CG8tlMRGHub8lSeYiTvcpAhM aHepgfWLizfRVqDi7BTRvVjnn+KKcOfFfLP3el2UF780xvS1ae9chWQSgu2sO9yeQTGnGe/Vjgf8v RbQknJHEOkRt7LQ3AQHymck4JlIiDAImbxy0Aq71lEgSZLP23d6QZkFYdKenlE0N2+wAMDN9KEjmF 28nlF9WqA==; Original-Received: from [76.77.182.20] (port=64188 helo=Takver4) by host2007.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1jKPlE-004Enq-1j for emacs-devel@gnu.org; Fri, 03 Apr 2020 11:05:40 -0600 In-Reply-To: <83369lxbwn.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 03 Apr 2020 10:32:08 +0300") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host2007.hostmonster.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - stephe-leake.org X-BWhitelist: no X-Source-IP: 76.77.182.20 X-Source-L: No X-Exim-ID: 1jKPlE-004Enq-1j X-Source-Sender: (Takver4) [76.77.182.20]:64188 X-Source-Auth: stephen_leake@stephe-leake.org X-Email-Count: 1 X-Source-Cap: c3RlcGhlbGU7c3RlcGhlbGU7aG9zdDIwMDcuaG9zdG1vbnN0ZXIuY29t X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 192.185.50.108 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:246340 Archived-At: Eli Zaretskii writes: >> From: Stephen Leake >> Date: Thu, 02 Apr 2020 17:55:36 -0800 >> >> > But why do you need that initial full parse in the first place? Is >> > parsing parts of the buffer so much harder? >> >> Because the parser must see a complete top level grammar statement. In >> Ada, that's the whole file; a typical file looks like: > > OK, so this depends on the language, and is not a universal > requirement. Yes. > the point I think we should take from this is that the font-lock > infrastructure should not _force_ the parser to always perform a full > parse, it should delegate that to the parser or to a language-aware > layer that calls the parser. Yes. >> Use case: A c-mode buffer A is currently displayed in a window in a >> frame, it is syntactically correct, and all displayed faces are correct. >> In another frame, the user uses 'M-x set-variable' to change the value >> of font-lock-function-name-face. >> >> To update the display, something has to trigger redisplay of buffer A. I >> don't think using M-x set-variable in a different frame does that. > > That's not so. Redisplay is called every time Emacs is about to > become idle. It just returns almost immediately if it detects that no > changes happened since last redisplay that require any work. I guess > this fast return is what you mean by "not triggering redisplay". Ok. > Regarding the above use case, I don't think I understand what exactly > did you mean. First, you cannot use set-variable to modify the value > of font-lock-function-name-face, because it isn't a defcustom. > Second, what exactly did you mean to set it to, to cause the effect > you were talking about? IOW, can you present a complete recipe, > starting from "emacs -Q", where you make such a change, and then you > need to switch buffers to cause function names be displayed > differently? I can tell you that if you replace "M-x set-variable" > with "M-x customize-face" and change some attribute of > font-lock-function-name-face, the effect on another frame is > immediate, which means redisplay takes note of the change and redraws > the other frame. But I'm not sure this is the same use case you had > in mind. Ok. In this case, customize-face causes the redisplay. So your original objection to the ada-mode face design, which was: > And they cannot pick up every relevant change; for example, what > happens if some face used for font-lock is modified? is moot. Unless some elisp program modifies the variable without using customize-face, but then that program has the responsibility for forcing redisplay. If there are other things that can be changed that should force a redisplay, but currently don't, I would say that's a bug, either in ada-mode or elsewhere. So far there have been no bugs filed against ada-mode for this type if issue. -- -- Stephe