emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [POLL] Should we accept breaking changes to get rid of Org libraries


From: Ihor Radchenko
Subject: Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?
Date: Tue, 28 Mar 2023 10:02:56 +0000

Max Nikulin <manikulin@gmail.com> writes:

> On 26/03/2023 00:45, Ihor Radchenko wrote:
>> I am then CCing Bastien, as, despite the Elisp convention, following it
>> will break https://bzg.fr/en/the-software-maintainers-pledge/
>
> I hope, it may be mitigated to some degree, e.g. loading of 
> `org-modules' and `org-babel-load-languages' may include their 
> activation. Perhaps `org-require-package' should activate the loaded 
> package as well.

We often promise in the manual that simple `require' is sufficient.
Not everybody is using `org-modules' mechanism.

Also, `org-require-package' is unrelated. It is specifically designed to
handle third-party packages where we have no control about side effects.

> If it is possible to avoid user prompt in org-ctags then migration may 
> be done in 2 steps separated by a year: add new require helper and do 
> not activate by default. Unsure if it is possible to add some warnings 
> on first step that activate function is not called.

There is no point discussing how to introduce the breaking change.
Making the transition longer will not make it non-breaking.
We first need to decide if we want to go ahead at all.

>> (defun enable-feature (feature &optional filename noerror)
>>    "Load and enable FEATURE.
>> FILENAME and NOERROR arguments are the same as in `require'."
>>    (when (require feature filename noerror)
>>      (let ((enabler-cmd (intern (format "%s-enable-function" feature))))
>>        (and (fboundp enabler-cmd) (funcall enabler-cmd)))))
>
> I would prefer activating on first call only, subsequent calls should be 
> no op.

Sure. I just wanted to point out that it is an easy part to implement
such functionality.

>> (defun disable-feature (feature)
>
> I had a hope that existing `unload-feature' is enough.

`unload-feature' serves different purpose, no?
I am not sure if mixing the two will be welcome by Emacs devs, if we
really want to pursue inclusion this into Emacs.

-- 
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>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]