From: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] LSP support in org-src buffers
Date: Tue, 11 Oct 2022 16:52:22 -0700 [thread overview]
Message-ID: <877d157wax.fsf@gmail.com> (raw)
In-Reply-To: <87mta5ease.fsf@localhost>
> 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.
I hadn't considered this. This makes context-aware org-src support even more important.
> 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.
This will drastically simplify the patch, true. I was working on the assumption that since tangling overwrites the file on disk, it should not be an implicit operation invoked as a side-effect of another action. It causes other changes that the user might not have intended, like updating timestamps on the tangled file, etc. What do you suggest?
Moreover, for Eglot to function correctly it is sufficient to (i) associate the buffer with a file -- any file, and (ii) Set the default-directory variable to the correct value. "Tangling" to a file in /tmp (as I do in the patch) will not work with all the non-Eglot use-cases you describe above.
> 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.
If I reuse the actual tangling machinery in ob-tangle instead of writing my own version reusing only some of the primitives in this library, this should be handled automatically for me. Is this correct?
> 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.
That's a giant improvement over the current implementation. I'll keep this in mind when working on the patch.
Also: org-src-context-mode works by advising some org-edit-src-* functions. Is it preferable to edit these functions directly instead and add a check for whether org-src-context-mode is enabled?
Karthik
next prev parent reply other threads:[~2022-10-11 23:53 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
2022-10-11 23:52 ` Karthik Chikmagalur [this message]
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=877d157wax.fsf@gmail.com \
--to=karthikchikmagalur@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@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).