emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Treesit says grammar is unavailable when it


From: Eli Zaretskii
Subject: Re: Treesit says grammar is unavailable when it
Date: Fri, 15 Dec 2023 11:00:03 +0200

> From: Madhu <enometh@meer.net>
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]