Karthik Chikmagalur <karthikchikmaga...@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>