[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] LSP support in org-src buffers
From: |
Ihor Radchenko |
Subject: |
Re: [PATCH] LSP support in org-src buffers |
Date: |
Wed, 12 Oct 2022 14:43:50 +0800 |
Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:
>> 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?
>
> 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.
Then, I suggest to not actually write things on the disk. Instead, we
can augment `org-edit-src-save' to write on disk depending on some
customization (with values t, nil, and 'ask). That customization will,
by default, make `org-edit-src-save' query user if it is desired to
write files on disk.
Also, note that once you associate buffer with a file, various
auto-saving mechanisms may write the file to disk without user consent.
We may also need to look into write-contents-functions to prevent such
scenarios when undesired.
>> 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?
No.
`org-edit-special' will _not_ expand noweb.
`org-babel-expand-src-block' will.
In the first case, <<noweb>> syntax may drive native syntax checkers
crazy. In the second case, care should be taken to prevent editing the
noweb-replaced text. This distinction is something we would not want to
break.
Also, be aware that some <<noweb()>> references may involve code execution,
possibly on remote machines. Remote execution might be undesired during
normal editing. I am not 100% sure how to approach this problem in a
reliable way that will fit all the uses.
> 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?
I am not even sure if a separate org-src-context-mode is needed. It
could be simply a customization for org-edit-special rather than a minor
mode.
So, I am all for editing the functions directly and more complete
integration.
--
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>