Re: Getting tree-sitter grammars in Guix

[Demis Balbach]

On 2023-01-22 16:38, Simon Tournier wrote:

> Hi,
>
> On Tue, 10 Jan 2023 at 18:29, Demis Balbach  wrote:
>
>> Hello, I was wondering what the "correct" way would be to get grammars
>> for the tree-sitter library available in Guix when using tree-sitter
>> with Emacs 29+.
>
> This raises a question about the bootstrap.
>
> From my understanding, the inputs of Tree-sitter is the file
> ’grammar.js’ and then using Node.js, it generates C files.  It is often
> these C files which are considered as the Tree-sitter parser.
>
> Many Tree-sitter parsers are available [1].  For example, Bash [2].  The
> grammar is described by ’grammar.js’ [3] and then using it, the file
> ’src/parser.c’ [4] is generated (note the size 3.46MB!).  Then, using
> this file ’src/parser.c’ is generated a library which is called by the
> editor tool (say Emacs tree-sitter [5]).
>
> I am not aware if someone has tried to rebuild using Guix only from the
> grammar.js to a working tree-sitter editing experience.
>
> Well, considering the state of Node.js and Guix, it appears to me
> difficult to debootstrap.   And maybe, we should accept a large
> unverified seed for Tree-sitter.  Well, I do not know.
>
> What people think?  What do we do with Tree-sitter?
>
>
> 1: 
> 2: 
> 3: 
> 4: 
> 5: 
>
>
> Cheers,
> simon

Hello Simon,

Thanks for the input. I came across this:

https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00073.html

Maybe this can be used as a foundation. I tested it locally and it works
fine, but I don't know how it needs to be altered in order to be pushed
upstream.

On that note, how would one package an emacs package that leverages
tree-sitter? I want to package https://github.com/isamert/jsdoc.el which
requires tree-sitter. I wrote a package definition where I substituted

My understanding is that I need to provide emacs with tree-sitter
support as an input for that to work. Here's a package definition I wrote:

--8<---cut here---start->8---
(define-public emacs-jsdoc
  (let ((commit "2e7c02ff2dc422bc21c405bd90a7092c2f599630")
(revision "0")
(version "0.2"))
(package
 (name "emacs-jsdoc")
 (version (git-version version revision commit))
 (source
  (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/isamert/jsdoc.el";)
 (commit commit)))
   (sha256
(base32 "07sz5lpyqv7ixvnnzdfjkj7f0ykdz31lkljp13pvlf36a6sff4rc"))
   (file-name (git-file-name name version
 (build-system emacs-build-system)
 (arguments
  `(#:phases
(modify-phases
 %standard-phases
 (add-after 'unpack 'patch-bin
(lambda* (#:key inputs outputs #:allow-other-keys)
  (substitute* "jsdoc.el"
   (("'tree-sitter") "'treesit")))
 (inputs
  (list
   ;; tree-sitter
   emacs-next-pgtk-stable
   emacs-s
   emacs-dash))
 (home-page "https://github.com/isamert/jsdoc.el";)
 (synopsis "Inserts JSDoc function comments/typedefs easily.")
 (description "Inserts JSDoc function comments/typedefs easily.
It also tries to infer types by itself while doing that.
Type inference is quite primitive.")
 (license license:gpl3+ 
--8<---cut here---end--->8---

My understanding is that I need to provide emacs with tree-sitter
support as an input for this to work, which I did, but it'll fail with

--8<---cut here---start->8---
Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such 
file or directory" "treesit")
--8<---cut here---end--->8---

Maybe someone can help me here. I tried looking at other package
definitions, but I don't know if there are any emacs packages that
require tree-sitter packaged in Guix yet.

Thanks in advance.

-- 
Best regards / Mit freundlichen Grüßen,
Demis Balbach


signature.asc
Description: PGP signature

Re: emacs packaging: do we need to pull existing dependencies ?

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 01.02.2023 um 08:44 +0100 schrieb Cayetano Santos:
> [D]o we need to pull most up-to-date dependencies, even if already  
> present in current emacs, when upstream package requires them to 
> keep backward compatibility ? Do we assume that guix emacs (28.2) 
> already includes them, and remove the dependency from the inputs ? Is
> it a good strategy to deal with two different versions of a 
> dependency?
The proper Guix way would actually be to unvendor those packages from
Emacs and offer them separately.  We could certainly do this for quite
a number (e.g. org, cc-mode, ...), but it would be work that someone
has to do and that person better not be lazy like me and take several
months to add native-compilation ;)

> Say for example emacs-org-roam@2.2.2: it requires emacs-org 9.4, 
> which is not specified in the package definition, meaning we always 
> pull the latest available. Do we have to, provided that emacs
> releases with org? Maybe there is already a clear rule about this
> topic, but to me this is not clear. We have package definitions with
> both criteria.
I think it's important to think about this in terms of forward
compatibility.  Is org-roam guaranteed to always work with "the current
version of Emacs, whatever that may happen to be"?  In that case, you
could currently drop emacs-org.  If it requires bleeding edge symbols
on the other hand, or may freely decide that it will need them, adding
emacs-org to the inputs is a good idea.


Cheers

Re: Reducing useless module imports

[Maxime Devos]

On 03-02-2023 18:11, Julien Lepiller wrote:

gnu packages minetest) imports (guix build-system
minetest) but never uses the minetest-build-system. (gnu packages
abiword) uses (guix build-system gnu) but does not use the
gnu-build-system.



The build-system minetest-build-system does not exist; it's 
minetest-mod-build-system, which happens to be defined in (guix 
build-system build-system).  As such, (gnu packages minetest) actually 
does use (guix build-system minetest).


The idea was that in the future we might also package 'subgames' and 
texture packages, for which a 'minetest-subgame-build-system' and 
'minetest-texture-pack-build-system' build system could be defined.
It seemed a bit pointless to me to put those not-yet-defined build 
systems in separate modules.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature