Re: [PATCH] LSP support in org-src buffers

[Ihor Radchenko <yantar92@gmail.com>]

Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:

> I've added limited support for LSP via Eglot in org-src-mode buffers.  I was intending to publish it as a package but it was suggested to me that it could live as part of Org instead, especially now that Eglot is intended to be part of the upcoming Emacs release.  Here are some details:
> ...
> It allows you to run Eglot in org-src buffers opened with org-edit-special (C-c '), giving you context-aware completion, linting, code actions etc.
> ...
> The main problem with reconciling org-src-mode and Language Server (LS) support is that the LSP requires and expects files, not buffers.  By default, org-src buffers are not associated with files.  Even if one were to associate an org-src-mode buffer with a file, set the correct default-directory for a project and start Eglot, it would only contain the small chunk of code from the current code block.  The LS cannot access enough code to form a useful picture of the project.

Thanks for your interest in contributing to Org core!

Transparent code editing in org-src buffers is certainly a feature that
is requested by many. Starting from people complaining about flycheck
giving nonsense errors in org-src buffers extending to any other serious
development work that relies on the existing project development
toolchains.

This is not limited to Eglot support. M-x compile, eglot, project.el,
xrefs, and similar tools all assume that current code buffer is
associated with a real file in a real project folder, possibly
containing all kinds of hints like .gitignore, .dir-locals.el, etc.

> org-src-context-mode reuses the tangling machinery to populate an org-src buffer with code from all blocks associated with the current tangle file, and associates it with a temporary file.  This way, the LS has a better picture -- if still limited to a single file -- of the project.
>
> org-src-context-mode then checks if there's an appropriate Eglot LSP connection active, and reconnects to it.
>
> Only the contents of the current code block are editable.  The other blocks are marked read-only and (by default) only visible by widening the buffer.  No actual tangling is done -- the default-directory of the org file is not touched at all.

This sounds a bit fragile and full of caveats.

You already implemented a way to associate the org-edit-src buffer with
the fully tangled code. Then, why not make it simple and do the real
tangling first and then make org-edit-src work directly with a real
file buffer associated with the tangled file?

All the tools, including Eglot will then work naturally and as intended.

The only tricky problem I am seeing with your approach is dealing with
noweb references. Care should be taken about editing code blocks
containing noweb.

> (v) org-src-context-mode does some pseudo-tangling -- this is required to specify what constitutes a "file" for the LS to parse. This adds a performance penalty to org-edit-src-code that can be noticeable if you have many (100+?) code blocks with the same tangle file as the current block.

Our to-be-released main branch does tangling orders of magnitude faster.
For example, my config.org with 660 src blocks tangles within 1.3 sec.

This can be made even faster by extra caching if there is a real demand
for super-fast tangling.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>