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