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

[Drew Adams <drew.adams@oracle.com>]

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