lin Sun writes:
> I use the `setopt` in my dot-emacs now, and won't make code changes.
> Please feel free to close this ticket, and any code change to enhance
> the discussed issue is welcome. Thanks
Ok.
Canceled.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode
Hi Ihor,
I use the `setopt` in my dot-emacs now, and won't make code changes.
Please feel free to close this ticket, and any code change to enhance
the discussed issue is welcome. Thanks
lin Sun writes:
> Thank you all for the comments, and agree with no code change.
> Please feel free to close this ticket. Thanks
Will you still be interested to improve the patch covering all other
cases in Org code where babel backend is used? Or using
`add-variable-watcher'?
--
Ihor
Ruijie Yu writes:
>> And it is not us who needs to use `setopt', but users.
>> We just have to deal with de facto situation with users using `setq'
>> mindlessly.
>
> Makes sense. So, does that mean nothing should be changed, except for
> maybe some additions to documentation mentioning that
Thank you all for the comments, and agree with no code change.
Please feel free to close this ticket. Thanks
Ihor Radchenko writes:
> Ruijie Yu writes:
>
>>> 1. `setopt' already triggers loading when variable is set. It is just
>>>`setq', often used in place of `setopt', that does not trigger
>>>loading/unloading.
>>
>> Speaking of which, since we now (or are about to?) depend on compat, we
Ruijie Yu writes:
>> 1. `setopt' already triggers loading when variable is set. It is just
>>`setq', often used in place of `setopt', that does not trigger
>>loading/unloading.
>
> Speaking of which, since we now (or are about to?) depend on compat, we
> can just do (require 'compat) and
Ihor Radchenko writes:
> lin Sun writes:
>
>> Thanks for the comment.
>> If we switch to the `add-variable-watcher', it seems we'll load the
>> ob-LANG in the callback immediately.
>> The previous change can lazyly load the babel languages until the user
>> tries to evaluate the source block.
lin Sun writes:
> Thanks for the comment.
> If we switch to the `add-variable-watcher', it seems we'll load the
> ob-LANG in the callback immediately.
> The previous change can lazyly load the babel languages until the user
> tries to evaluate the source block.
Is there any advantage doing the
Hi Ihor,
Thanks for the comment.
If we switch to the `add-variable-watcher', it seems we'll load the
ob-LANG in the callback immediately.
The previous change can lazyly load the babel languages until the user
tries to evaluate the source block.
lin Sun writes:
> On Sat, Apr 22, 2023 at 12:42 PM Ihor Radchenko wrote:
>> the cleanest way will be using `add-variable-watcher'.
> The "add-variable-watcher" may not be able to deal with the
> local/global variable `org-babel-load-languages' correctly.
May you elaborate?
--
Ihor Radchenko
On Sat, Apr 22, 2023 at 12:42 PM Ihor Radchenko wrote:
> the cleanest way will be using `add-variable-watcher'.
Hi Ihor,
The "add-variable-watcher" may not be able to deal with the
local/global variable `org-babel-load-languages' correctly.
On Sat, Apr 22, 2023 at 8:33 AM Ruijie Yu wrote:
>
lin Sun writes:
> Before the error message, the patch will give a try to load the
> associated babel language.
>
> Why does the language exist in the `lang org-babel-load-languages' but
> not be loaded?
> Because the `org-babel-load-languages' are defined as a customer
> variable with :set
lin Sun writes:
> Hi,
> The function `org-babel-execute-src-block' will emit an error message
> if the language is not loaded.
>
> Before the error message, the patch will give a try to load the
> associated babel language.
>
> Why does the language exist in the `lang org-babel-load-languages'
Hi,
The function `org-babel-execute-src-block' will emit an error message
if the language is not loaded.
Before the error message, the patch will give a try to load the
associated babel language.
Why does the language exist in the `lang org-babel-load-languages' but
not be loaded?
Because the
15 matches
Mail list logo
