[FR] Provide a way to activate packages automatically for side effect

[FR] Provide a way to activate packages automatically for side effect

[Ihor Radchenko]

Hello,

The very first suggestion in D.1 Emacs Lisp Coding Conventions is to
avoid side effects when loading a library:

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

The request not to change editing experience is reasonable, but it is
sometimes hard to draw a line when side effects of the loading should be
separated into an explicit command/function users have to run/add to the
config.

For example, when a package defines a new major mode, it is common to
modify `auto-mode-alist' by merely having such package installed.
This is technically a change in Emacs's editing behavior.

Another example is when a package adds new features to an existing
functionality, like ert.el where mere (require 'ert) changes
fontification in emacs-lisp-mode buffers:
(add-hook 'emacs-lisp-mode-hook #'ert--activate-font-lock-keywords)

If one follows "Lisp Coding Conventions" explicitly, the above examples
can be seen as breaking the conventions.
On the other hand, it is very clear that autoloading a major mode is
justified because otherwise why would user install the relevant package?

Similar argument can be made for changing the fontification rules in
ert.el - if ert library is loaded _by the user_, it is very clear that
the erc.el features, including fontification, are going to be useful.

The situation is not so clear when a library is autoloaded by the means
of building completion list (`help-enable-completion-autoload') - side
effects in such case may be surprising to the user who merely wanted to
read some obscure docstring.

May it be possible to introduce an alternative way to load
packages/libraries other than `require' with an intention to be used as
a part of user config?

What I have in mind is something like
(enable-package 'name) that will (1) load the package without side
effects; (2) "enable" the package, producing useful side effects
intended for interactive use.

Further, (use-package name) can be modified to automatically run
(enable-package 'name); and package.el can be modified to mark packages
installed explicitly (via M-x package-install or other interactive
means) to be automatically "enabled" after loading (add (eval-after-load
'name (enable-package 'name).

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

RE: [External] : [FR] Provide a way to activate packages automatically for side effect

[Drew Adams]

> For example, when a package defines a new major mode, it is common to
> modify `auto-mode-alist' by merely having such package installed.

That's common?  It shouldn't be.  Loading/installing
code shouldn't do that, even for a "new major mode".

> This is technically a change in Emacs's editing behavior.

Not just technically - really, practically.

> Another example is when a package adds new features to an existing
> functionality, like ert.el where mere (require 'ert) changes
> fontification in emacs-lisp-mode buffers:
> (add-hook 'emacs-lisp-mode-hook #'ert--activate-font-lock-keywords)

Ditto.

> If one follows "Lisp Coding Conventions" explicitly, the above examples
> can be seen as breaking the conventions.

Not just "can be seen as".  They break the conventions.

> On the other hand, it is very clear that autoloading a major mode is
> justified because otherwise why would user install the relevant package?

Not for the package to guess why.  Up to the user.

> Similar argument 

What's the argument?  Is it just "otherwise why would
a user install..."?  That's not an argument.

> can be made for changing the fontification rules in
> ert.el - if ert library is loaded _by the user_, it is very clear that
> the erc.el features, including fontification, are going to be useful.

It's not clear that that's clear to the user, or that
(more importantly) the user wants those changes made.
___

Just one opinion.  No opinion about whether some more
lax new kind of load function might be useful.

RE: [External] : [FR] Provide a way to activate packages automatically for side effect

[Ihor Radchenko]

Drew Adams <drew.adams@oracle.com> writes:

>> For example, when a package defines a new major mode, it is common to
>> modify `auto-mode-alist' by merely having such package installed.
>
> That's common?  It shouldn't be.  Loading/installing
> code shouldn't do that, even for a "new major mode".

Sorry, but the manual itself contradicts your assertion:

24.2.1 Major Mode Conventions
   • If you want to make the new mode the default for files with certain
     recognizable names, add an element to ‘auto-mode-alist’ to select
     the mode for those file names (*note Auto Major Mode::).  If you
     define the mode command to autoload, you should add this element in
     the same file that calls ‘autoload’.  If you use an autoload cookie
     for the mode command, you can also use an autoload cookie for the
     form that adds the element (*note autoload cookie::).  If you do
     not autoload the mode command, it is sufficient to add the element
     in the file that contains the mode definition.

So, I am 100% sure that modifying auto-mode-alist in particular is a
side effect that is perfectly fine, even recommended.

>> On the other hand, it is very clear that autoloading a major mode is
>> justified because otherwise why would user install the relevant package?
>
> Not for the package to guess why.  Up to the user.
>
>> Similar argument 
>
> What's the argument?  Is it just "otherwise why would
> a user install..."?  That's not an argument.

This is an argument. Installing the package implies that the user wants
to use that package. Asking to add Elisp incantations other than the
usual require/use-package (limited, well-known set of callables) just
embraces the culture of copy-paste without understanding and annoys
users.

>> can be made for changing the fontification rules in
>> ert.el - if ert library is loaded _by the user_, it is very clear that
>> the erc.el features, including fontification, are going to be useful.
>
> It's not clear that that's clear to the user, or that
> (more importantly) the user wants those changes made.

I can see this kind of argument, although do note that what I propose -
a way to "enable" package with all the side effects - will _reduce_ side
effects of autoloading because there will be less pressure on package
authors to produce such side effects for user convenience.

I thus read your argument as "-1" for automatically enabling packages
that are installed explicitly - by clicking "install" in package menu or
M-x package-install.

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

RE: [External] : [FR] Provide a way to activate packages automatically for side effect

[Drew Adams]

> >> For example, when a package defines a new major mode, it is common to
> >> modify `auto-mode-alist' by merely having such package installed.
> >
> > That's common?  It shouldn't be.  Loading/installing
> > code shouldn't do that, even for a "new major mode".
> 
> Sorry, but the manual itself contradicts your assertion:
> 
> 24.2.1 Major Mode Conventions
>    • If you want to make the new mode the default for files with certain
>      recognizable names, add an element to ‘auto-mode-alist’ to select
>      the mode for those file names (*note Auto Major Mode::).  If you
>      define the mode command to autoload, you should add this element in
>      the same file that calls ‘autoload’.  If you use an autoload cookie
>      for the mode command, you can also use an autoload cookie for the
>      form that adds the element (*note autoload cookie::).  If you do
>      not autoload the mode command, it is sufficient to add the element
>      in the file that contains the mode definition.
> 
> So, I am 100% sure that modifying auto-mode-alist in particular is a
> side effect that is perfectly fine, even recommended.

OK.

> >> Similar argument
> >
> > What's the argument?  Is it just "otherwise why would
> > a user install..."?  That's not an argument.
> 
> This is an argument. Installing the package implies that the user wants
> to use that package. 

For real "use", sure.  But just to try?  Just load once?

(I'm not very knowledgeable about packages.  I'm thinking
in terms of just loading Lisp code.  If I'm missing
something wrt "installing" a package, then please ignore.)

> >> can be made for changing the fontification rules in
> >> ert.el - if ert library is loaded _by the user_, it is
> >> very clear that the erc.el features, including fontification, are going to be useful.
> >
> > It's not clear that that's clear to the user, or that
> > (more importantly) the user wants those changes made.
> 
> I can see this kind of argument, although do note that what I propose -
> a way to "enable" package with all the side effects - will _reduce_ side
> effects of autoloading because there will be less pressure on package
> authors to produce such side effects for user convenience.

That sounds good to me: a way to _optionally_ enable all
or some such side effects, letting users choose.

I suggested that such a possibility have its own function
or whatever, as opposed to changing existing behavior
under the same names.

> I thus read your argument as "-1" for automatically enabling packages
> that are installed explicitly - by clicking "install" in package menu or
> M-x package-install.

I guess that's right.  Ideally users should be able to
either just load a package with no side effects, or
load a package allowing a default set of side effects
- or even with a user-chosen set of side effects.

Anyway, just a naive opinion from someone not very well
acquainted with using packages.  Feel free to ignore,
of course.