Re: [POLL] Should we accept breaking changes to get rid of Org libraries that perform side effects when loading?

[Max Nikulin]

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.

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.

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

> (defun disable-feature (feature)

I had a hope that existing `unload-feature' is enough.

My idea was something like `org-require' that is (require feature) and 
(feature-activate) or (feature-activate-function) *once*.