Rudolf Adamkovič <[email protected]> writes: >> Well... See https://list.orgmode.org/orgmode/87edsd5o89.fsf@localhost/ >> where one of the ideas is to save choice in current buffer. > > I am lost in the thread. It contains 54 A4 pages of text. Would this > be more complicated than `(setq-local org-confirm-babel-evaluate nil)` > executed when the user picks "yes for all code blocks in this buffer"?
I was only referring to the specific email I linked to. See "What we can do ..." What I proposed there is indeed more complicated - a superset of buffer-local org-confirm-babel-evaluate. In any case, it was about adding a new choice when confirming evaluation, not replacing the defaults. >> All the relevant functions that are checked by babel code for >> existence. Or we can change things in ob-core and require some kind of >> org-babel-load:<lang> to be autoloaded. Then, everything that currently >> check for specific function names will first try "load" method. > > The more I think about this idea, the more I like it. It would simplify > configuration and improve performance as well, as Org Babel libraries > would be loaded "as needed", instead of batch-loaded on launch. > > To test the idea, I removed `(require ob-python)' from my config and > added `###autoload' to `org-babel-execute:python'. I was able to > execute a Python block. > > Now the question is how *exactly* we could implement the idea. > > For autoloads, we have discussed 3 approaches: > > (1) put the `###autoload' cookie on > > - org-babel-execute:LANG > - org-babel-load-session:LANG > - org-babel-initiate-session:LANG > - org-babel-prep-session:LANG > > (2) introduce auto-loaded `org-babel-load:LANG' function. > > (3) we could try to load `ob-LANG' library. > > These approaches could be combined as follows: > > - only (1) > - only (2) > - only (3) > - both (1) and (3) > - both (2) and (3) > > The big advantage of (3) is that many 3rd-party libraries would "just > work", without users or developers updating anything. > And, an important side-question is what we do with > > (A) org-babel-do-load-languages > (B) org-babel-load-languages. > > I suppose (A) would be soft-deprecated in documentation and (B) would be > consulted only for `nil', as in "this language is explicitly disabled"? > Or, would we replace both with one simple `org-babel-disabled-languages' > customization that does what it says on the tin, with no loading magic? Respecting disabled languages clashes with the idea of autoloads. On the other hand, if some third-party library does provide autoloads, it is already not respected anyway... So, we should probably deprecate org-babel-load-languages and instead fully switch to lazy loading. At the end, its main purpose is speeding up loading Org, which lazy loading achieves anyway. People generally ever disable languages in org-babel-load-languages when they are loaded by default but not being used. I think I prefer 2 over 1 because putting an autoload cookie on several defuns risks that some cookies may be forgotten, creating subtle bugs. (3) is fine. -- Ihor Radchenko // yantar92, Org mode maintainer, 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>
