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: Wed, 1 Apr 2020 09:47:48 -0600 Message-ID: References: <83369o1khx.fsf@gnu.org> <83imijz68s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000048dfe605a23c9de1" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="91597"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?UTF-8?B?VHXhuqVuIEFuaCBOZ3V54buFbg==?= , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 01 17:51:19 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 1jJfeB-000NjH-6w for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Apr 2020 17:51:19 +0200 Original-Received: from localhost ([::1]:33824 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJfe8-00067z-W8 for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Apr 2020 11:51:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53043) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJfbO-00035Y-Rx for emacs-devel@gnu.org; Wed, 01 Apr 2020 11:48:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jJfbN-0000Br-JG for emacs-devel@gnu.org; Wed, 01 Apr 2020 11:48:26 -0400 Original-Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:36929) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jJfbN-0000Bd-Cg for emacs-devel@gnu.org; Wed, 01 Apr 2020 11:48:25 -0400 Original-Received: by mail-wm1-x32f.google.com with SMTP id j19so246441wmi.2 for ; Wed, 01 Apr 2020 08:48:25 -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=isUfRhVXIyXQfZXo/c1fLOMIkKuuYqidkrdqFPl1wkc=; b=ZfXUeHrv3PugGy1NdLaIRZOD42OrncB05ur6CcVqV2+TtLVX2+zrnhVZZqUJmw1uCW i7LqitMdiPx/Y7Tvf+aQtgX4JTNgnE/h1mSoQdfrQtbsFFeE+N1H9gmxuBAhlmQUUGJ2 hgnY3wpW/3qHf6/BY0KlWPA+F+/eagzwm8mrsbpQeWTiYBXKDX0sX65ZiDMxFAYmNg1/ nIhEseIGCEdaScJ/18LqEM/KmwNaycBih26iMsQ+vNe/sC+OpqY1m6rx/hvvJhY24KyG uB5ADk+Etwu9h+DKoCPVicGptXQz5OuwLQfLmfxClIcqX8fJ1Pg8gjZQglOYYbr/Z5Ir noVA== 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=isUfRhVXIyXQfZXo/c1fLOMIkKuuYqidkrdqFPl1wkc=; b=O3Tug0PIK3mOg4Wbpk2zYoGaDai0sui57qFKOJkqnqyn6KaXUy3x1KoksDjzXUs8/N ESC71qF961mGRRrrE0AqiJlbk341Hdy50YCnI1eWCONfkbww7423qq3YjrB3UOG5ekg3 ewUve54neNRVVpaXNFN0/KaSmmkPaQw8P2sF4689FZCAMn45TKvJM8VLDOLqQpx4zwgY TmZT+qe3/dggHf1EdMhBmLJ1bvnVFH60eT/3UagB8iKm/8YqwFboNeTasNNPdlU7wsq+ RrqbqaBYlILU8adXQ7QmtRIxene2B7htbtEycfO3hAmo3zZMJyCjx9fv2159ivvMR8sH /P8A== X-Gm-Message-State: AGi0PubNtBZrGr32ldrWgvjLYbSNLjasSAisLeX9QulN5XlHQivtddtk Uk6YzX3tnllgWQRWbWhvFBRPOUVLqyW9svgM8jhL7dlq5+FbMgoY X-Google-Smtp-Source: APiQypJ6DF+75sYNIxuicT5JebB/WXQpG3MEOm/SX2NHHJ23Jnz6bkgoM3AITmt01XMIUTQrsbg1itXrl55f+hksFzw= X-Received: by 2002:a1c:1bd2:: with SMTP id b201mr5119486wmb.181.1585756104083; Wed, 01 Apr 2020 08:48:24 -0700 (PDT) In-Reply-To: <83imijz68s.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::32f 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:246206 Archived-At: --00000000000048dfe605a23c9de1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Did you consider using the API where an application can provide a function to return text at a given offset? Such a function could be relatively easily implemented for Emacs. But why not just allow access to buffers for dynamic modules, otherwise what would be the point of dynamic modules? El mi=C3=A9., 1 de abr. de 2020 a la(s) 07:26, Eli Zaretskii (eliz@gnu.org) escribi=C3=B3: > > From: Tu=E1=BA=A5n Anh Nguy=E1=BB=85n > > Date: Wed, 1 Apr 2020 13:17:42 +0700 > > Cc: emacs-devel@gnu.org > > > > Real usage with "xdisp.c": > > > > (define-advice tree-sitter--do-parse (:around (f &rest args) > benchmark) > > (message "%s" (benchmark-run (apply f args)))) > > > > (0.257998 1 0.13326100000000096) > > And that is even without encoding the buffer text, IIUC what the > package does. > > > So yes, direct access to buffer's text from dynamic modules would be > nice. > > Did you consider using the API where an application can provide a > function to return text at a given offset? Such a function could be > relatively easily implemented for Emacs. > > Btw, what do you do with the tree returned by the tree-sitter parser? > store it in some buffer-local variable? If so, how much memory does > such a tree take, and when, if ever, is that memory released? > > --00000000000048dfe605a23c9de1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Did you consider using the API where an applicatio= n can provide a function to return text at a given offset?=C2=A0 Such a fun= ction could be relatively easily implemented for Emacs.

But why not just allow access to= buffers for dynamic modules, otherwise what would be the point of dynamic = modules?

El mi=C3=A9., 1 de abr. de 2020 a la(s) 07:26, Eli Zarets= kii (eliz@gnu.org) escribi=C3=B3:
> From: Tu=E1=BA= =A5n Anh Nguy=E1=BB=85n <ubolonton@gmail.com>
> Date: Wed, 1 Apr 2020 13:17:42 +0700
> Cc: emacs-dev= el@gnu.org
>
> Real usage with "xdisp.c":
>
>=C2=A0 =C2=A0 =C2=A0(define-advice tree-sitter--do-parse (:around (f &a= mp;rest args) benchmark)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(message "%s" (benchmark-run (appl= y f args))))
>
>=C2=A0 =C2=A0 =C2=A0(0.257998 1 0.13326100000000096)

And that is even without encoding the buffer text, IIUC what the
package does.

> So yes, direct access to buffer's text from dynamic modules would = be nice.

Did you consider using the API where an application can provide a
function to return text at a given offset?=C2=A0 Such a function could be relatively easily implemented for Emacs.

Btw, what do you do with the tree returned by the tree-sitter parser?
store it in some buffer-local variable?=C2=A0 If so, how much memory does such a tree take, and when, if ever, is that memory released?

--00000000000048dfe605a23c9de1--