From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Michael Welsh Duggan Newsgroups: gmane.emacs.devel Subject: Re: emacs-tree-sitter and Emacs Date: Thu, 02 Apr 2020 14:50:18 -0400 Message-ID: References: <83eeta3sa0.fsf@gnu.org> <86369ojbig.fsf@stephe-leake.org> <83lfnfz6jr.fsf@gnu.org> <864ku3htmb.fsf@stephe-leake.org> <83v9mix9vk.fsf@gnu.org> <87pncq55f8.fsf@md5i.com> <83imihyl42.fsf@gnu.org> <83h7y1yikx.fsf@gnu.org> <83d08pyc8f.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="76549"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: mwd@md5i.com, stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 02 20:51: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 1jK4vs-000Jp5-UH for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Apr 2020 20:51:16 +0200 Original-Received: from localhost ([::1]:46082 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK4vr-0005II-Te for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Apr 2020 14:51:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58827) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK4vF-0004lE-FY for emacs-devel@gnu.org; Thu, 02 Apr 2020 14:50:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jK4vD-0002vb-P8 for emacs-devel@gnu.org; Thu, 02 Apr 2020 14:50:36 -0400 Original-Received: from veto.sei.cmu.edu ([147.72.252.17]:49778) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jK4vB-0002sq-Da; Thu, 02 Apr 2020 14:50:33 -0400 Original-Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 032IoRGO031187; Thu, 2 Apr 2020 14:50:27 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 032IoRGO031187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1585853427; bh=/Vu+D1TmIPPJ8iscWEs/UqWKaWEkNilE1ERaSmnStJE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Vpxio2otEzKs0wb2b6q/AHKn16heOAa+j6yCvAxxZTN9jVc6vJLH6RuPPTt6yYf9n DNbMhcxmDLWWGq5w983tRCjTVft0Td7pGtdJpe1e7jgjIbjhxTkyjoFBqzmss5s2FY +35UE+U1YLYP2Tbfy0lLAKYxZ1W7Pp80q9yGJd4Q= Original-Received: from lx-birch.ad.sei.cmu.edu (lx-birch.ad.sei.cmu.edu [10.64.53.120]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 032IoJmr008655; Thu, 2 Apr 2020 14:50:19 -0400 Original-Received: from lx-birch.ad.sei.cmu.edu (localhost [127.0.0.1]) by lx-birch.ad.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 032IoJ31006413; Thu, 2 Apr 2020 14:50:19 -0400 Original-Received: (from mwd@localhost) by lx-birch.ad.sei.cmu.edu (8.14.7/8.14.7) id 032IoIPT006410; Thu, 2 Apr 2020 14:50:18 -0400 X-Authentication-Warning: lx-birch.ad.sei.cmu.edu: mwd set sender to mwd@cert.org using -f In-Reply-To: <83d08pyc8f.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 2 Apr 2020 21:27:28 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 147.72.252.17 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:246287 Archived-At: Eli Zaretskii writes: >> From: Michael Welsh Duggan >> Cc: , , >> Date: Thu, 02 Apr 2020 12:19:44 -0400 >> >> >> > Each buffer always knows which part of it remains unchanged. When >> >> > fontification is invoked, it should start from that place. So there's >> >> > no need to parse _all_ prior context. >> >> >> >> Why not? Won't it miss that hypothetical opening comment delimiter, for >> >> example? >> > >> > No, because that was already taken care of when that comment delimiter >> > was inserted. >> >> In which case it's covered by the paragraph you omitted. > > I don't think it is, because you were talking about parsing the full > buffer, whereas I'm talking about parsing only what affects the > display in the window. No, not really. Though I think it's just miscommunication on my end. Let me sum up what I believe has been said. I don't claim to be correct in any of this, but it is what I believe is the current set of facts: In normal usage, these external parsers are supposed to work like this: 1) Parse the whole file. (This is a step that I believe you'd like to avoid, but I'm talking about how it is intended to work right now.) 2) At this point the parser holds a parse tree and can be asked questions about syntactic information about any portion of the buffer. 3) Subsequently any change to the buffer is sent to the parser (just the change) which updates its view of the world and it's internal parse state. 4) After each change, the parse might communicate some of its syntactic information back to the program using it, or it might just wait for the program to ask more questions. Of this, I am uncertain. If this is correct, I also think we could avoid (1) as an optimization. In this case we only send the text from (save-restriction (widen) (point-min)) to (window-end) to the parser as soon as the buffer is visible. Then treat scrolling down as a change that adds text to the buffer (from the parser's point of view). This may not produce correct semantic information in all cases, but it is probably a reasonable first approximation in the event that we want to avoid (1). If we were to do this, we would probably want to make this configurable. Now that I have hopefully communicated my understanding, now people can express how I have misunderstood and/or just gotten this completely wrong. Which is just fine, and hopefully I will have learned something in the process. -- Michael Welsh Duggan (mwd@cert.org)