From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Tree-sitter integration on feature/tree-sitter Date: Sat, 18 Jun 2022 11:50:55 +0300 Message-ID: <83edzmnymo.fsf@gnu.org> References: <2c2746e5f2558a87e8eab6f0914264a020173a9d.camel@pm.me> <27630AA3-8026-4E24-8852-ACCD9325B99D@gmail.com> <0E9E702B-B07C-4794-8498-29B9320E14CC@gmail.com> <83letvq0ii.fsf@gnu.org> <6EA831D3-A9C9-4346-B1E8-7748BAB285E2@gmail.com> <83czf7pocp.fsf@gnu.org> <83tu8io5i5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13191"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 18 10:55:57 2022 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 1o2UFJ-0003M5-7H for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jun 2022 10:55:57 +0200 Original-Received: from localhost ([::1]:53882 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2UFH-0002fa-Rb for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jun 2022 04:55:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40700) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2UAY-0000m6-Iv for emacs-devel@gnu.org; Sat, 18 Jun 2022 04:51:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60460) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2UAX-00018l-NV; Sat, 18 Jun 2022 04:51:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=E3Ix40tcrMZBxFcFbjEy0W8Qf2oxeaX8PnfRae96vBY=; b=TyMcrDH/ZS/OTuA9wVmU TSqxFZhkKGGTNG8FhoGX7ySavJqSqP9m7GbeOoknoV7xTKwOoch/slSse3XnTCF42mmIfds36z0kT gLnrkC7FeXb8CHh7dF9BOVpbk1jNezuSmubnoHXaymesGLIg9nHpFqlxONn0Uu1hcVGpi5NSm54zp lCGu9pxr9LpigdDTrTBdzN85SMQmHfUGeMTQut2l7cTh4qJHEXSbrIJSxwLeD5VO0dQfg72m7RyqT QrD9RYxId8LGjBjYvZDw6oqOA/luLiIv72PRdBL2/A73Sjt9WdgWVKaB+03O7qm3iS1XiZu6GwqBR 2FpqeFJMbtmTQw==; Original-Received: from [87.69.77.57] (port=1409 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2UAW-0005fq-NT; Sat, 18 Jun 2022 04:51:01 -0400 In-Reply-To: (message from Yuan Fu on Sat, 18 Jun 2022 01:25:01 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:291350 Archived-At: > From: Yuan Fu > Date: Sat, 18 Jun 2022 01:25:01 -0700 > Cc: emacs-devel@gnu.org > > >>> Then removing a parser means we actually delete it? > >> > >> Not sure what do you men “delete”. > > > > If creating a parser adds it to the list, then I guessed the semantics > > of removing from the list is the opposite: having the parser no longer > > exist, i.e. "delete" it. > > > > But now I'm confused by what you say here: > > > >> Treesit-parser-delete removes the parser from the parser list of a buffer, so it is never kept up-to-date with that buffer again. But you can still do stuff with it until it is gc’ed. > > > > If we already have treesit-parser-delete, and that call removes the > > parser from the list, then why would we need a function "to remove a > > parser from the list"? It sounds like treesit-parser-delete already > > does it? > > Yeah. There is no other function, treesit-parser-delete deletes and removes the parser. So you agree with me that a function to remove from the list is not needed? Once the list is no longer exposed to Lisp, the way Lisp programs should manipulate the list is by adding and deleting parsers, and by asking Emacs to show the list of existing parsers. Right? > Though I don’t know how can you make a Lisp_Object “no longer exist”. Normally we just turn # into #, right? Yes, we leave the actual deleting to GC.