From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Jorge Javier Araya Navarro Newsgroups: gmane.emacs.devel Subject: Re: Reliable after-change-functions (via: Using incremental parsing in Emacs) Date: Tue, 31 Mar 2020 11:19:22 -0600 Message-ID: References: <83o8sf3r7i.fsf@gnu.org> <2E218879-0F24-4A20-B210-263C8D0BEEA4@gmail.com> <838sjh2red.fsf@gnu.org> <83369o3bvb.fsf@gnu.org> <83imik1qbq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f6e74905a229c6fe" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="125341"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org, casouri@gmail.com, akrl@sdf.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 31 19:21:14 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 1jJKZe-000WRS-8g for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 19:21:14 +0200 Original-Received: from localhost ([::1]:42106 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJKZd-000755-9W for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 13:21:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49502) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJKYU-0005Cg-5W for emacs-devel@gnu.org; Tue, 31 Mar 2020 13:20:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jJKYS-0007yp-Us for emacs-devel@gnu.org; Tue, 31 Mar 2020 13:20:02 -0400 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:38519) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jJKYS-0007wW-JU for emacs-devel@gnu.org; Tue, 31 Mar 2020 13:20:00 -0400 Original-Received: by mail-wm1-x333.google.com with SMTP id f6so3742491wmj.3 for ; Tue, 31 Mar 2020 10:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=esavara-cr.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yN/MwD66vBhc/+zx3elBirc+8Q4WvcyDh9i/Mf6eJ9Q=; b=R3zJzXVIqBtatQgC5Nd/3zEFUjlhp+KmQOp+dSpdb5asrNJEdIT2cnNuDHgIoWMXO/ 5wTpWt9n6VEXYebWIrTqQRldkVBxTvGIBZ9zEMsZaTytNz6YJ6fbJDa73zbxIY1KP2rQ fYhq3S6YwF5t+8BBi21R5ZcGZOkRLqHgJRQPXC9qIbHX1oI0eewGTjGFUXV30xZwRD52 vbmXqOHfqp/n0uQEZdh92DnwWm5RXIbnxTG9F0BKZg3Q5jYjS8PSqBaUc8m+lF9m74MD ofAy8t9Lxxn3dMWz/lnLF8jwgMfjwnTGkXOVXuUpMGZkwJDcr1DfA2koU3rOXc9V65KG BpSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yN/MwD66vBhc/+zx3elBirc+8Q4WvcyDh9i/Mf6eJ9Q=; b=GwIGcZ6QXbHDqaMT+JsYpp9oBfu7sVx1aWYeB1zUpUaKs4IYiYD2J1WRYFB6GnxJxJ fvCkfQvQu8v1FUnOHCg964x7Ajx2aW7t4n0b4B9YAgOvlbIkcY9CESFF26YIt/wbie97 OUpw2/sWnM5zMVA0RIQyGQHtaZl7Nr8c1jYSOfqHoPKx+x7/CNBSLfd8wtsS8QOQAMWC 3cD7D/+tSqMHb3bW3uDJtiCVd/YW6td8SmE+083+kEPC8LnaleTywhZ8mGPWWi5Uqijz pnqAjKP1J8OS4IgzKb4gPXjn9y7c0SIj0vjJ+VuToD3dsSf4enNNAczKqtEmTTBHAqK0 RRbw== X-Gm-Message-State: ANhLgQ32uP/9s89SpqglDKDi/5RZP9C58lV8D1rnmqVVbAEIO2ZUh2MG E8SobOCJt+fcLj94yhvgCSeQlTdO23ZvSnhzVI+2mQ== X-Google-Smtp-Source: ADFU+vuOcZe1Yka9VgAnBVOqgFP9Y1TNsWXXMgxv7N+8znzRZzz0s8yJCFud9SrlGEA4Q3Tauyiyev2R6Pz8umDYHQo= X-Received: by 2002:a1c:cc16:: with SMTP id h22mr4287537wmb.47.1585675198976; Tue, 31 Mar 2020 10:19:58 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::333 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:246129 Archived-At: --000000000000f6e74905a229c6fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >>> How large is "very large" here? >> xdisp.c comes to mind, obviously. > > I'd expect tree-sitter to be able to parse xdisp.c in one second or less. It's funny because this can be tested doing a C program, sadly I don't have the time now for writting it. El mar., 31 de mar. de 2020 a la(s) 11:10, Stefan Monnier ( monnier@iro.umontreal.ca) escribi=C3=B3: > >> > I still don't see why it would need the entire buffer for this class > >> > of applications. Did anyone try the alternatives, in particular on > >> > very large buffers? > >> What alternatives? > > Let tree-sitter see just a portion of the buffer, like the outer block > > of what will be displayed in the window. You are saying that this is > > impossible, > > I think it would be definitely possible if you present "from point-min > to POS". But "from START to END" is much more difficult, yes. > > > but do tree-sitter developers also say that? > > You'd have to ask them. But what I say is based on the knowledge > I gleaned by reading the academic literature that the tree-sitter > authors cite (I did that while working on an article on SMIE ;-) > > In any case, your question is really about the design of tree-sitter > rather than the design of the interface between tree-sitter and Emacs. > > AFAICT tree-sitter is pretty close to the state of the art in this area, > so I think it's worth trying it out to see how it performs before > considering changing its design. > > >> How large is "very large" here? > > xdisp.c comes to mind, obviously. > > I'd expect tree-sitter to be able to parse xdisp.c in one second or less. > > > Stefan > > > --000000000000f6e74905a229c6fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>> How large is "very large" here?
>> xdisp.c comes to mind, obviously.
>
> I'd expect tree-sitter to be able to parse xdisp.c in one second o= r less.

=
It's funny because this can be tested doing a C program, sadl= y I don't have the time now for writting it.

=
El mar., 3= 1 de mar. de 2020 a la(s) 11:10, Stefan Monnier (monnier@iro.umontreal.ca) escribi=C3=B3:
>> > I still don= 9;t see why it would need the entire buffer for this class
>> > of applications.=C2=A0 Did anyone try the alternatives, in pa= rticular on
>> > very large buffers?
>> What alternatives?
> Let tree-sitter see just a portion of the buffer, like the outer block=
> of what will be displayed in the window.=C2=A0 You are saying that thi= s is
> impossible,

I think it would be definitely possible if you present "from point-min=
to POS".=C2=A0 But "from START to END" is much more difficul= t, yes.

> but do tree-sitter developers also say that?

You'd have to ask them.=C2=A0 But what I say is based on the knowledge<= br> I gleaned by reading the academic literature that the tree-sitter
authors cite (I did that while working on an article on SMIE ;-)

In any case, your question is really about the design of tree-sitter
rather than the design of the interface between tree-sitter and Emacs.

AFAICT tree-sitter is pretty close to the state of the art in this area, so I think it's worth trying it out to see how it performs before
considering changing its design.

>> How large is "very large" here?
> xdisp.c comes to mind, obviously.

I'd expect tree-sitter to be able to parse xdisp.c in one second or les= s.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan


--000000000000f6e74905a229c6fe--