Thanks for the warm welcome and the amount of inputs and details that
everybody so fast provides.
I'm really impressed by this community.
Ok seems that delivering a language specification in EBNF has some
challenges that can hardly be addressed due to the nature of org-mode
design, but I read around that often EBNF is not the silver bullet to solve
a grammar representation although it is a de-facto standard.
So I will try to put some orders in my thoughts, when I look at
functionalities of org-mode I will split them in the following categories:
- Grammar Specification
- Metadata
- TODO
- Code Block
- Tangling (or waving for the web people)
- Properties of the file
- Templating
- Block Execution
- Environment (Global variables such as PATH)
- Language
- Context for arguments
- Publishing Functions
- Target Format
- Custom Parser
I share a lot with of your ideas and inputs, here some observations and
options that I noticed:
- Indeed emacs is not that big and could run as a background process to
deliver org-mode features to other systems.
I do something very similar to *TEC* for my CI/CD and my static
generated website, but I'm not sure I would run emacs as a web service.
- LSP doesn't mention org-mode as available language, but it does for
markdown
https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocumentItem
maybe because org-mode is not a language?
- I share the sentiment that some api are a bit obscure and most
important there isn't for instance an official way to say "this is how you
create extensions in org".
- I found that multiple people are already converting org-mode into json
by using org*-map-entries *which indeed is not very publicly shown (I
miss something like "this is how you create extensions in org").
- I relate a lot to the issues that *Tom Gillespie* discusses in his
post (
https://lists.gnu.org/archive/html/emacs-orgmode/2020-10/msg00244.html)
about tangling and executions and I loved to see your efforts in trying to
solving them.
- Since gccemacs elisp could compile to C (not sure this is relevant,
but can be investigated if there are opportunities to be capable to have
org-mode embendable).
For my personal needs I think I would pragmatically start toying around
with a org-mode to json like here https://github.com/ludios/org-to-json
And once I gain some confidence on the output JSON, I think I will gain
more confidence about the grammar definition.
I think that converting org-mode to JSON could show org-mode as an Abstract
Syntax Tree, I think from there it should be easier to create a
specification and maybe is what already *orgajs
<https://github.com/orgapp/orgajs>* already did.
I believe creating functions like tangle and execution shouldn't be that
trivial from an AST.
Concluding,
there is overlap between the Interfaces of LSP and org-mode which makes a
lot of sense since both target the interaction for with a document eg:
- Propose actions, these can be:
- Execute
- Tangle
- Change state TODO
- Insert date, tag, etc...
- Go to definition (For linking sections)
- Support multi language in the same document
This makes me think that creating an org-mode LSP is not that crazy idea
after all, what do you think?
If you would build an LSP for org-mode which setup would you choose? What
do you think would be hard to implement?
Again many thanks 🙏
Mauro.
