Re: Where to place third-party C source code?

[Eli Zaretskii]

> From: Jorge Javier Araya Navarro <address@hidden>
> Cc: address@hidden
> Date: Sat, 28 Sep 2019 01:33:40 -0600
> 
> > I don't see why we would need this method, since tree-sitter is a
> > library, and Emacs can be linked against that library.  What you quote
> > is an alternative method, but why would we need such an alternative?
> 
> Well, yes, I realized that adding an option to configure.ac would allow the 
> compiler to find the
> source code of Tree Sitter (like `--with-tree-sitter=/some/path/tree-sitter' 
> or who knows)

Why would building Emacs require access to the tree-sitter's source
code, even if we decide to provide this feature in core Emacs?  Isn't
linking against a library good enough?

> > Of course, this is all putting the wagon ahead of the horse: we should
> > first discuss whether we want to have Emacs be able to link to that
> > library and provide the related features.  An alternative would be to
> > have an unbundled module that uses the Emacs module API.
> 
> Ah, yes. There is one project that provides tree-sitter like a dynamic module 
> using the Emacs module
> API[1], but my concern is: why should vanilla Emacs require their final users 
> to download a bunch of
> packages to make the user experience better when we could, like, literally, 
> provide them from the
> get-go? IIRC one pain-point of Emacs for (new?) users is how much 
> configuration is needed to have a
> better editing experience.

There's no contradiction between better experience and having this
particular feature be implemented as a module.  We've added the module
API precisely for cases like this one, where some feature needed
access to the Emacs internals on the C level.

Making this part of the Emacs core would need to write some C code in
Emacs itself, and link against the library, it still won't need any
access to the sources of tree-sitter.  We could do that, but we
need first to be sure that this is worth our while, i.e. that having
that feature through an external module will somehow be insufficient,
or if most Emacs users will want to have that.  AFAIU, none of these
reasons were brought up and justified yet.  Improving the user
experience is not of itself a sufficient reason, because every
additional feature basically does that in some sense.  We need a more
serious reason, one that will justify the additional maintenance
burden that will put on the Emacs project in the long run.