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: Reliable after-change-functions (via: Using incremental parsing in Emacs) Date: Thu, 02 Apr 2020 17:09:30 +0300 Message-ID: <83tv22x9lx.fsf@gnu.org> References: <83imik1qbq.fsf@gnu.org> <835zek1kpv.fsf@gnu.org> <83v9mkz5oo.fsf@gnu.org> <83pncsym6l.fsf@gnu.org> <4a9d6bb2-458d-89b0-5389-d1f883ef24a1@yandex.ru> <20200401135237.GA6240@ACM> <83d08rz48f.fsf@gnu.org> <5d5e4fac-2f83-455e-d3e0-51b28c27bfb5@yandex.ru> <837dyzyyzg.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="69403"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, casouri@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, akrl@sdf.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 02 16:10:20 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 1jK0Y0-000Hy5-F0 for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Apr 2020 16:10:20 +0200 Original-Received: from localhost ([::1]:40720 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK0Xz-00030W-GR for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Apr 2020 10:10:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55979) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK0XV-0002W8-Go for emacs-devel@gnu.org; Thu, 02 Apr 2020 10:09:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:57445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jK0XU-0005WV-96; Thu, 02 Apr 2020 10:09:48 -0400 Original-Received: from [176.228.60.248] (port=1233 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jK0XT-0005QU-OO; Thu, 02 Apr 2020 10:09:48 -0400 In-Reply-To: (message from Dmitry Gutov on Thu, 2 Apr 2020 00:21:36 +0300) 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:246258 Archived-At: > Cc: acm@muc.de, akrl@sdf.org, casouri@gmail.com, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Thu, 2 Apr 2020 00:21:36 +0300 > > > If by TreeSitter you mean the parser (not the Emacs package which > > interfaces it), then what I proposed is not against their design, > > AFAIU. They provide an API through which we can let the parser access > > the buffer text directly, and they explicitly say that the parser is > > tolerant to invalid/incomplete syntax trees. And I don't see how it > > could be any different, since when you start writing code, it takes > > quite some time before it becomes syntactically complete and valid. > > That makes sense, at least in theory. But I'd rather not break the usage > assumptions of the authors of this library right away. >From what I could glean by reading the documentation, the above is not necessarily against the assumptions of the tree-sitter developers. I saw nothing that would indicate the initial full parse is a must. That such full parse is unnecessary is what I would expect, because of the use case that I start writing a source file from scratch. > And we'll likely want to adopt existing addons which use the result > of the parse, which likely depend on the same assumptions. Those other addons must also support the "write from scratch" use case, right? Then they should also support passing only part of the buffer, since it could be that this is all I have in the buffer right now. > Anyway, here's a (short) discussion on the topic of large files: > https://github.com/tree-sitter/tree-sitter/issues/222 Thanks. This was long ago, though, so I'm not sure what became of that (and Stefan's comment didn't yet get any responses to indicate that this is a solved problem).