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

[Ihor Radchenko]

Bastien Guerry <bzg@gnu.org> writes:

>> This is convincing.
>> I am then CCing Bastien, as, despite the Elisp convention, following it
>> will break https://bzg.fr/en/the-software-maintainers-pledge/
>
> FWIW, in this case, the mistake lies in breaking the Emacs Lisp coding
> convention first.  When the breaking change is a side-effect of fixing
> a bug, it is unavoidable.

The situation is a bit more complex.
Strictly speaking, loading Elisp library _always_ has side effects of
defining new functions. And, for example, Org babel's behavior is
modified when ob-foo.el is loaded because `fboundp' on
'org-babel-execute:foo returns non-nil.

A bit different approach is used for ol-foo.el, where more significant
side effect is triggered by top-level calls to
`org-link-set-parameters'. Similarly, ox-foo.el uses
`org-export-define-derived-backend' or `org-export-define-backend'.

Finally, we have org-mouse.el discussed here, which modifies key
bindings and org-inlinetask.el, which modifies how Org treats headlines
in Org files, modifying syntax.

With the current state of affairs, it is often enough to
(require 'org-library) to get things work. If we get rid of all the
possible side effects, users will have to adapt their configurations
and we will thus violate "I won't force you to update your
configuration."

Of course, we can change babel implementation to use explicit registry
like for export backends and force users to call explicit activation
commands in addition to (require 'library). But I am not sure if we are
not crossing the line with such an approach: "I won't use software
correctness as an excuse.".

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