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

[Nick Dokos]

Max Nikulin <manikulin@gmail.com> writes:

> On 08/08/2023 20:29, Bastien Guerry wrote:
>> The definition of a new function is not a side-effect
>> that affects Emacs editing behavior, so Babel and export libs are
>> OK.
>
> Function definition is not side effect when load library is
> requested. However it is a side effect of hitting TAB in Emacs help
> prompt. Completion of a variable or a function should not modify Org
> behavior. Loading of a file is not explicitly requested by the user in
> this case.
>
> I would disregard however function definitions, however changes in key
> bindings and recognized plain text links may be surprising to users
> who just tries to read help.
>
>

A big +1 from me: that's exactly what I was trying to say a few months
ago wrt org-ctags, although I said it badly. Defining functions that
are not used is not much of a problem IMO, but changing behavior behind
the user's back is most definitely a problem. IOW, it's not about
side-effects in general, it's about *specific kinds* of side-effects:
ones that are immediately visible (and confusing) to the user - things
behaving differently from a minute ago even though the only thing the
user did in-between is something as innocuous as asking for help.

One small step forward is to require libraries to have explicit
enable/disable functions[fn:1].  Even if I somehow enable a library by
mistake or misadventure, I should be able to disable it (at least in
the sense described above) without having to restart. Not every
library will need that and it's not even close to a complete solution,
but there is at least the possibility of building something better
(though more complicated) on top of it. If the library could be
organized as a minor mode, it most definitely should be so organized:
enabling/disabling would then be an automatic "requirement satisfied".

I would also recommend that the library *not* call its enable function
in general and leave it to the user to do so explicitly, but that may
be more controversial for "backward compatibility" reasons (with which
I disagree in these particular cases: I view them as bugs that need to
be fixed). And the library should document what changes it unleashes
on the environment (again in the restricted sense discussed above):
changes to "foreign" keymaps/menus/syntax tables/hooks probably
qualify for this kind of documentation, function definitions and
internal-to-the-library changes do not, plus there is probably a swath
of stuff in-between with more ambiguous requirements - all I can say
is start with the obvious things and add as necessary.

[fn:1] E.g. `org-ctags' has `org-ctags-enable' but no `org-ctags-disable', so
my "solution" is to do something like this in my init file:

    ;;; undo org-ctags obnoxiousness
    (with-eval-after-load 'org-ctags (setq org-open-link-functions nil))

It doesn't undo everything but it gets the obnoxious bits out of my
way (at least until *I* decide to call `org-ctags-enable').

My 2-cents/pence/centimes...
-- 
Nick