Ihor Radchenko <yanta...@posteo.net> writes:

> Max Nikulin <maniku...@gmail.com> writes:
>
>>> Sure. This is not by itself a big deal. A number of Elisp libraries,
>>> including built-in Emacs libraries are loaded with side effects.
>>
>> It is still violation of conventions:
>>
>> (info "(elisp) Coding Conventions")
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
>>> D.1 Emacs Lisp Coding Conventions
>>> 
>>> Simply loading a package should not change Emacs’s editing behavior.
>>> Include a command or commands to enable and disable the feature, or to
>>> invoke it.
>>> 
>>> This convention is mandatory for any file that includes custom
>>> definitions. If fixing such a file to follow this convention requires an
>>> incompatible change, go ahead and make the incompatible change; don’t
>>> postpone it.
>
> 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.

-- 
 Bastien

Reply via email to