GNU bug report logs - #49946
[PATCH 00/31] Tree-sitter, node-gyp addon support and emacs-tree-sitter

Previous Next

Full log

View this message in rfc822 format

From: Pierre Langlois <pierre.langlois <at> gmx.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: Pierre Langlois <pierre.langlois <at> gmx.com>, 49946 <at> debbugs.gnu.org, Luis Henrique Gomes Higino <luishenriquegh2701 <at> gmail.com>
Subject: [bug#49946] [WIP PATCH v3 00/26] gnu: Add tree-sitter for emacs (and neovim as well?).
Date: Thu, 10 Mar 2022 13:19:34 +0000

[Message part 1 (text/plain, inline)]

Maxime Devos <maximedevos <at> telenet.be> writes:

> [[PGP Signed Part:Undecided]]
> Pierre Langlois schreef op do 10-03-2022 om 11:17 [+0000]:
>> Before continuing to work on this build-system though, do you have
>> any
>> opinions about adding it to begin with?  As opposed to the current
>> approach of defining a base grammar package (see tree-sitter-c) and
>> have
>> the other grammar packages inherit from it.  I'm wondering if it's
>> worth
>> adding the build-system, when I don't think we should expect the
>> number
>> of grammars we would package to grow too much.  But then again, the
>> package definitions do look quite a bit nicer with the build-system,
>> so
>> I'm a bit on the fence about this :-).
>
> Build systems only cost a module or two, there are quite a few tree
> sitter packages (19 or so?) and the tree sitter packages have a lot
> in common (custom test phases, install phases), so I wouldn't
> hesitate to define a custom build system for tree-sitter stuff.

Sounds good, I'll continue in that direction for v5.

>
> Even better would be to unify things a bit more, e.g. it looks like
> tree-sitter-ocaml needs a custom 'install', 'build' and 'check' phase,
> but they looks almost the same as the other phases for other treesitter
> packages, so maybe 'tree-sitter-build-system' can be taught to mostly
> automatically determine the exact invocation?  

I'll see what can be done, sadly so far I couldn't find a way to do the
right thing automatically for ocaml and typescript.  These are packages
that provide two grammars, and I didn't see a way to "discover" that
there are multiple languages supported.  However maybe they could be
split into multiple package definitions, if I can find a way to do that,
maybe by passing new #:keyword parameters.

Another idea could be to call back into the build-system phase, for
example something like:

--8<---------------cut here---------------start------------->8---
(replace 'build
  (lambda _
    (for-each (lambda (dir)
                (with-directory-excursion dir
                  ((assoc-ref tree-sitter:%standard-phases 'build))))
              '("ocaml" "interface"))))
--8<---------------cut here---------------end--------------->8---

I don't know if that works yet, we could do that if other nicer
approaches don't work.

>
> Also, 'use-modules' only really works on the top-level, I recommend
> #:modules instead, there are some problems with using it in expression
> context (I don't think they are documented anywhere though).

Ah, I see I had (use-modules (guix build json) (ice-9 regex)) in the
install phase for no reason indeed, those modules were already imported,
that's what you meant right?

Thanks for your input!  I'll work on a v5.
Pierre

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.