emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] LSP support in org-src buffers
Date: Sun, 09 Oct 2022 15:06:09 +0800	[thread overview]
Message-ID: <87mta5ease.fsf@localhost> (raw)
In-Reply-To: <87bkqmdhqz.fsf@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>


  parent reply	other threads:[~2022-10-09  7:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-08  5:08 [PATCH] LSP support in org-src buffers Karthik Chikmagalur
2022-10-08 12:50 ` Christopher M. Miles
2022-10-09  7:06 ` Ihor Radchenko [this message]
2022-10-11 23:52   ` Karthik Chikmagalur
2022-10-12  6:43     ` Ihor Radchenko
2022-11-21  3:19       ` Ihor Radchenko
2022-11-21 14:39 ` João Pedro
2022-11-22  2:23   ` Ihor Radchenko
2022-11-22  8:21     ` Cook, Malcolm
2022-11-22  8:44       ` Ihor Radchenko
2023-07-27  8:01         ` [TASK] Making org-src buffers sync with real files to allow LSP and other dev tools integration (was: [PATCH] LSP support in org-src buffers) Ihor Radchenko
2022-11-30  4:35     ` [PATCH] LSP support in org-src buffers João Pedro
2022-12-12 13:16       ` Ihor Radchenko
2022-12-15 19:24         ` João Pedro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mta5ease.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=karthikchikmagalur@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).