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

[Ihor Radchenko]

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>