From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-tree-sitter and Emacs Date: Fri, 03 Apr 2020 10:32:08 +0300 Message-ID: <83369lxbwn.fsf@gnu.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> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="94892"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 03 09:33:07 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 1jKGp6-000OY5-PX for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 09:33:04 +0200 Original-Received: from localhost ([::1]:51392 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKGp5-0002zW-Rx for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 03:33:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39023) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKGoT-0002XN-4A for emacs-devel@gnu.org; Fri, 03 Apr 2020 03:32:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jKGoS-00076C-NY; Fri, 03 Apr 2020 03:32:24 -0400 Original-Received: from [176.228.60.248] (port=4949 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jKGoQ-00014a-OI; Fri, 03 Apr 2020 03:32:24 -0400 In-Reply-To: <86a73tgwo7.fsf@stephe-leake.org> (message from Stephen Leake on Thu, 02 Apr 2020 17:55:36 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:246306 Archived-At: > 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. I expect that most languages are not like Ada. 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. > 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". 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. > >> The elisp manual section "Forcing redisplay" says "Emacs normally tries > >> to redisplay the screen whenever it waits for input." After I type the > >> first character, it is no longer waiting for input, it is processing > >> that character. I assume here "process that char code" includes running > >> after-change-functions, which is (small) elisp code. But I guess after > >> processing that char, before calling redisplay, it checks if there is > >> more input, which should be true if I type fast enough. Perhaps "process > >> that char code" is faster than the combination of my fingers and the > >> keyboard char send rate? > > > > Yes, most probably. > > Ok, so in practice, it is not possible to type fast enough, and > font-lock runs after every character typed. It's possible. One situation where this happens is when you have something expensive running after each command, for example some expensive post-command-hook. Another situation is to make your keyboard's auto-repeat be very fast, and lean on some key. Yet another is to run Emacs on an old and not-so-fast machine.