> 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