RE: How can i enable webmode?

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

> >> For example the Melpa package `inform' is activating itsel during
> >> installation (and maybe by restarting Emacs in some situations).
> The
> >> motivation is: If you are interested you'll have it without much ado
> >> and
> >> if you don't like it any more just uninstall the small package.
> >>
> >> Does it make sense or do you regard this behaviour as impolite?
> >
> > It's generally considered impolite, and is
> > contrary to convention.
> 
> Thank you for showing the Lisp coding convention.
> 
> And I accept these reasonable rules.  But I think there are also
> borderline cases where (small?) packages don't change editing behaviour
> and do not change existing code in any way.  And the its feature(s) can
> be completely removed by uninstalling the package.
> 
> Why would I download a package if I do not want to activate an
> advertised feature?  So this uncommon way can save unnecessary hassle,
> I hope.

First, a user may well want to download something
just to try it out, without wanting, say, changes
made to a local setup.  Or even just want to take
a look at the source code.  There's good logic,
and consideration of users, behind such guidelines.

But second, I personally agree that they should be
only guidelines (for 3rd-party coders), and such
guidelines have exceptions.

I think that what's really important/helpful is for
the Commentary in a library (source file), or some
other associated doc, to make clear what happens,
what the behavior is.

If a user uses a command, or loads a file, or turns
something on, s?he should know just what will happen.
If s?he then does that, knowing what will happen,
that's a user choice.

An example:

GNU Emacs policy/recommendation is that code should
not bind or set a user-option value. The idea behind
that (good, reasonable) guideline is that it's a
_user_ setting, and a user preference should be respected.

But what about a command or other user-choosable
construct whose very purpose is to change an option
value?  Does it make sense to outlaw providing such
things to users?  No, IMO.

For example, there are Isearch options, and there
are Isearch keys that temporarily have the effect
of toggling the behavior controlled by some such
options.  They actually toggle an internal variable,
without affecting the option value.  But what if
the point of a particular key/command is precisely
to change (e.g. toggle) an option, so that the
change affects not only the current Isearch but
also subsequent ones?

In such cases my own opinion differs from GNU Emacs
policy.  I don't feel constrained, in providing
3rd-party code, to never bind or even set option
values.  I do feel compelled to document behavior.
It's then up to users to choose whether to take
advantage of it.

Same thing applies to commands that might change
colors or whatever interactively.  IMO, there's
no reason that Customize should be the only way
for users to alter such state.  It's good, not
bad, to provide ways for users to incrementally
change appearance or behavior interactively.

But it's important that users be in control, that
they choose whether to do this or that, knowing
what behavior will result.

Just one opinion.

Understand that those guidelines came about
because there were too many Lisp files that did
change too many things just by loading them.
It was hard for users to work around that, undo
it, or sometimes even be aware that it was
happening.

It's understandable that this happens, because
the typical road to the creation of a 3rd-party
library often starts with someone's personal
customizations (with Lisp code).  Such a file
of code that changes behavior can evolve into
a library that others pick up.  And it's all too
easy for that evolution to skip steps of making
sure every behavior change becomes something
optional and undoable.

There are degrees.  And it's not always easy to
make everything optional and undoable.  A minor
mode is a good way to provide for optional
behavior, in general: key bindings, whatever.
But some changes of Emacs state are not so easily
reversed.  The most important thing, IMO, is to
be clear (document) what happens.