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