From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Third Newsgroups: gmane.emacs.devel Subject: Re: Reliable after-change-functions (via: Using incremental parsing in Emacs) Date: Tue, 31 Mar 2020 18:13:15 +0200 (CEST) Message-ID: <20200331161311.GA81462@breton.holly.idiocy.org> References: <83o8sf3r7i.fsf@gnu.org> <2E218879-0F24-4A20-B210-263C8D0BEEA4@gmail.com> <838sjh2red.fsf@gnu.org> <83369o3bvb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="127971"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org, Stefan Monnier , akrl@sdf.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 31 19:21:51 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 1jJKaE-000X9Z-2J for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 19:21:50 +0200 Original-Received: from localhost ([::1]:42112 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJKaD-00008c-4L for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 13:21:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41256) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJJW1-0006Eb-NL for emacs-devel@gnu.org; Tue, 31 Mar 2020 12:13:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jJJW0-0004Jf-3u for emacs-devel@gnu.org; Tue, 31 Mar 2020 12:13:25 -0400 Original-Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:35624) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jJJVx-0004I8-75; Tue, 31 Mar 2020 12:13:21 -0400 Original-Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 5AE0D60B; Tue, 31 Mar 2020 18:13:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1585671198; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; l=752; bh=4+p7S4XaYG70A+06kC3cyKGk8Zv8oOUSGvZ1nNGvJQ0=; b=GPjeFOvKo2w5OE2/YH/j3G8xJtEV3sPkupFZCUhMPRXWOXTP8Omo/kEdIel4pJ5M BZ2kutICFlKv3QgWCgW6AeEdBXDDihlJKKEFcZ3AmPkzCY/zYodPmYe+4czXWYkZ+gY tLPQjc51bDZDiZ0SoOoZeo220WSI6kuSM+65Z/CF2BdLOZ3r7/7MPfLnwmCrXFPmgKX lAaj74JpE0CaxO8oqwNboY5F7bgvvtK3ZgiWSvsx7j6b0zkn1LOAEiBgEdzE4JP4aUo YlqWa+SbpOwpRqquEUvhd6c1HlIvlMQT5ueZXzz/Rk8XUt7+4xq2DixGH+4JEt1s+4l 1nem3+neoQ== Original-Received: by smtp.mailfence.com with ESMTPSA ; Tue, 31 Mar 2020 18:13:13 +0200 (CEST) Original-Received: by idiocy.org (Postfix, from userid 501) id D8B4A202143B9A; Tue, 31 Mar 2020 17:13:11 +0100 (BST) Mail-Followup-To: Alan Third , Eli Zaretskii , Stefan Monnier , casouri@gmail.com, akrl@sdf.org, emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: <83369o3bvb.fsf@gnu.org> X-ContactOffice-Account: com:241649512 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.3.242.97 X-Mailman-Approved-At: Tue, 31 Mar 2020 13:19:29 -0400 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:246130 Archived-At: On Tue, Mar 31, 2020 at 04:14:16PM +0300, Eli Zaretskii wrote: > > In any case, I hope that passing the buffer to tree-sitter doesn't > involve marshalling the entire buffer text via a function call as a > huge string, or some such. We should instead request that tree-sitter > exposes an API through which we could give it direct access to buffer > text as 2 parts, before and after the gap, like we do with regex > code. Otherwise this will be a bottleneck in the long run, not unlike > the problem we have with LSP. I'm not sure if this is exactly what you're talking about, but it has an API for letting it access your own data structure: https://tree-sitter.github.io/tree-sitter/using-parsers#providing-the-code -- Alan Third