Max Nikulin <maniku...@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