Ihor Radchenko <[email protected]> writes:
>> Perhaps we could at least improve the user interface with Yes/No/Always
>> and then briefly flash "Customize `org-confirm-babel-evaluate' to save
>> your choice". Still, I would prefer no questions if (and only if) I
>> request code execution explicitly.
>
> 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"?
> 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?
WDYT?
Rudy
--
"Chop your own wood and it will warm you twice."
--- Henry Ford; Francis Kinloch, 1819; Henry David Thoreau, 1854
Rudolf Adamkovič <[email protected]> [he/him]
http://adamkovic.org
