[Pkg-octave-devel] Re: Inappropriate user-level configuration in system files

[Niels Möller]

Rafael Laboissiere <rafael at debian.org> writes:

> * Dirk Eddelbuettel <edd at debian.org> [2005-10-18 16:56]:
> 
> > On 18 October 2005 at 21:56, Rafael Laboissiere wrote:
> > | * Niels Möller <nisse at lysator.liu.se> [2005-10-17 13:57]:
> > | > Installing the octave-emacsen package should only install the octave
> > | > mode, and not fiddle with user preferences. It took me quite some time
> > | > to figure out why I suddenly had font-lock mode enabled in my emacs.
> > |
> > | I tend to agree with the bug submitter on this issue.  Dirk, since you
> > | are the original author of 50octave.el, I would like to know your
> > | opinion.
> > 
> > It's a config file, if Niels doesn't like it, he can comment it out and
> > his choice will be reflected. It is still a good default for most users
> > in my book, especially for those who wouldn't know how to set Emacs up
> > themselves.
> > 
> > So not a bug, and I'd close it.
> 
> Well, Dirk's arguments are also sound.  Niels, could you please comment
> on the above? 

I'd like to take the short version first.

> I am afraid we are arguing about personal tastes here.

The main problem is not the personal taste issue. Even if we could all
agree and decide that that in general, font-lock-mode is an excellent
default for debian users, this octave package is *not* the right place
to implement that decision. It's an inappropriate place to modify the
system defaults for user preferencecs such as font-lock-mode,
auto-fill-mode and abbrev-mode.

Now the longer version...


1. Policy

> Does the Policy or the Developers Reference say something about
> this issue?

I checked the Debian Emacs Policy before filing the bug report. I
couldn't find anything explicit about these configuration issues.
However, the way I read the emacs policy, the intention is that the
files under /etc/emacs/site-start.d should work as parts of emacs'
site-start.el. The documentation in startup.el in emacs says

  Don't use the `site-start.el' file for things some users may not
  like. Put them in `default.el' instead, so that users can more
  easily override them. Users can prevent loading `default.el' with
  the `-q' option or by setting `inhibit-default-init' in their own
  init files, but inhibiting `site-start.el' requires
  `--no-site-file', which is less convenient."

Following this advice also for debian makes a lot of sense to me. As
far as I'm aware, there's no mechanism for debian packages to add code
to be run from (or under the same circumstances as) default.el, which
means that there's really no good place for default preferences that
are specific for debian.


2. "if Niels doesn't like it, he can comment it out"

Sure I can do that. I happen to know the root password for the machine
(and maybe that's the common case for gnu/linux these days, each
machine has one user with the root password, and (hopefully) a single
user account for non-sysadmin tasks). But in the general multiuser
case, I would have asked root to install the octave packages, and then
I wouldn't have access to edit the system config file. I could ask
root to edit it for me, or more likely, I'd work around it in my
personal .emacs, but I couldn't edit the file myself. One shouldn't
assume that users have write access to the system configuration files.

Emacs has a fairly well designed division between system configuration
and user configuration, including ways for users to easily override
parts or all of the system configuration. I think this design should
be maintained in the debian packaging.


3. "It is still a good default for most users in my book"

If you believe that the upstream emacs defaults aren't user-friendly
enough for debian, then any tweaks should be part of some of the
*central* debian emacs packages. emacsen-common could have a
configuration file with defaults for user settings, and you could put
(global-font-lock-mode) there.

If every emacs add-on-package contains it's own configuration of user
preferences, each according to the package maintainer's personal
preferences, then the system will be inconsistent by default, and it
will be unnecessarily hard to change the configuration to make the
user experience consistent. You get a situation where *both* the user
who wants font-lock everywhere, *and* the user who doesn't want it,
needs to modify the configuration for a bunch of different packages.
And similarly for all other emacs features where users have different
tastes. That can't be the way to go, and it's *not* user-friendly.

I understand that you may want to have the default debian emacs look
prettier than a default emacs compiled from sources. One disadvantage
of such enhancements, is that personal emacs configuration files get
less portable. If I move my .emacs between debian, solaris, freebsd or
($DEITY forbid) w*ndows, it's nice if my configuration has the same
result on all systems. If emacs on each system comes with different
defaults for all user-configurable features, that won't work. The
portable .emacs file will have to be twice as long, because it doesn't
have a stable known default to start from.


4. Transparency and documentation.

If a user reads about font-lock-mode in the emacs documentation, and
how to configure it, she will read about M-x customize, .emacs and
default.el. How is the user supposed to find out that for font-lock
configuration, she is expected to be editing
/etc/emacs/site-start.d/50octave.el?

Finally, this can't be the first time issues like this have come up
for emacs packages. To me, it's obvious that the role of configuration
files such as /etc/emacs/site-start.d/50octave.el is to setup
autoloads and loadpath etc so that the package fits into the emacs
configuration, and leave everything else to (i) the emacsen-common
default configuration, (ii) local system configuration, e,g.,
default.el, (iii) personal configuration, e.g. .emacs. It would be
nice if the debian emacs packagers could discuss these issues, reach
some form of concensus, and document it in the emacs policy.

Regards,
/Niels