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

[Jorge Javier Araya Navarro <jorgejavieran@yahoo.com.mx>]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]



El sábado 28 de septiembre del 2019 a las 0031 horas, Eli Zaretskii escribió:

>> Date: Fri, 27 Sep 2019 21:29:52 +0000 (UTC)
>> From: Jorge Araya Navarro <jorgejavieran@yahoo.com.mx>
>>
>> I was wondering if placing third-party C source code that is used in any feature I would like to implement in the Emacs project is "against the rules", sort of speak.
>
> I don't understand the question.  Any feature supported by Emacs that
> needs C-level support has some C code in one of the Emacs C source
> files.  There's no "third-party" code, everything is part of Emacs
> proper.
>
>>     [...] you can use the library in a larger project by adding one source file to the project. This source file needs three directories to be in the include path when compiled:
>>
>>     source file:
>>     - tree-sitter/lib/src/lib.c
>>
>>     include directories:
>>     - tree-sitter/lib/src
>>     - tree-sitter/lib/include
>>     - tree-sitter/lib/utf8proc
>
> 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)

> 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.

We could leverage projects like tree-sitter to improve the user experience in Emacs out-of-the-box,
integrating tree-sitter with Emacs and ship the grammars of some programming languages that Emacs is
already shipped with (like Python and JavaScript) would improve the experience of editing code in
those languages first, and second in any other language supported with a third-party elisp packages,
without mentioning what this could mean in terms of the tooling available for package authors.

[1]: https://github.com/ubolonton/emacs-tree-sitter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]