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: Treesit says grammar is unavailable when it Date: Fri, 15 Dec 2023 11:00:03 +0200 Message-ID: <831qbnq1rg.fsf@gnu.org> References: <1b24fc47-f792-415c-ac59-fcf3a2f5eeb9@gmail.com> <83r0jqs46e.fsf@gnu.org> <83r0jpqjd9.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37859"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Madhu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 15 10:01:46 2023 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 1rE44n-0009gz-VZ for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Dec 2023 10:01:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rE43y-0004Q5-2t; Fri, 15 Dec 2023 04:00:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rE43k-0004Ob-Vr for emacs-devel@gnu.org; Fri, 15 Dec 2023 04:00:47 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rE43k-0003mN-5J; Fri, 15 Dec 2023 04:00:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=d2QLPl6Zx0Ns4fC9yztetr6dEYAMBODJfsId/lonb9o=; b=sKKANof2ZqWL Vb1y7L7BLNQIyn2zgxfn4q9/AA/YoZV0wsLhFae5jBG23JB9jpiVKS/rtFXrNdZdMcajDwfyl3Dbn v+5vys4AjGlORjbj0/QGymYDj39VeMwgHa2OYZmclcyDQvNisWkh0ZLeo2eqsHVaCXGXOlBsL/cLg MoIG7y7S5WNyWoxkntrBqt8ukrVMDna/Tflw0DF+dml65a8xxCVRLWVV1TTDDstyktZDuHJkxKFKe g5YKaUpZemVNLEn8oetDIILOw3yx/eEoUfvA+0WoUXwo9aQ9JV4Oho+fKE2a4TfaStwTL2expjmcn Cudse8u67aFjaHcYakPVQA==; In-Reply-To: (message from Madhu on Fri, 15 Dec 2023 08:13:14 +0530) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:313850 Archived-At: > From: Madhu > Date: Fri, 15 Dec 2023 08:13:14 +0530 > > I still think writing a lisp interface to dlopen and dlclose would iron > out a lot of things in the details and make it useful for treesitter > related stuff. Or is the locking down the ffi interface done for FSF > reasons? First, this particular aspect of Emacs is unrelated to the issue at hand, so I suggest a new thread with a different Subject. And second, we indeed don't want to allow loading arbitrary shared libraries into Emacs, except via the emacs-modules interfaces. It mostly will make no sense anyway, since you will not be able to use the loaded library without some glue code. The grammar libraries are a rare exception, because the tree-sitter library handles the glue. I also object to having a direct dlopen interface exposed to Lisp on the grounds that Emacs (unlike Guile, perhaps) is not a library for interfacing the OS via Lisp bindings. Emacs is a text-editing and text-processing environment, and therefore should hide the OS features behind suitable higher-level APIs. Like emacs-modules do, by extending 'load' and similar. That makes these features more portable, and allows writing Lisp programs that work on systems where dlopen per se is not available. > On another note, I also went through the same process with yaml-ts-mode, > A pointer to where the treesitter plugin is available is missing from > the docs. Then one has to turn to third parties for this information > and to find the providers and toolchain providers and do the dance to > their tunes. This is a job for downstream distros. I explained in the past several times why I object to making this our job. > But most disappointing thing was that the modes come with absolutely no > navigation functions. These are structured files, and emacs has provides > way to navigate the structures. This is a general quality defect from > to "prog" abstractions. (when the facililties are provided they are > inadequate and a dedicated mode would have taken the diligence to do it > right) We have some navigation capabilities, like movement by defuns. However, any reasonable extensions and improvements in this area will surely be welcome, but I think we need a more detailed feature requests for that. Thanks.