Re: Why is it not possible to use "nil" any more in init files ?

[phillip.lord@newcastle.ac.uk (Phillip Lord)]

Alexandre Oberlin <email_via_web@migo.info> writes:

> Thanks Phillip for your answer.
>
> You wrote:
>>> From my perspective, most people who write
>> (hated-mode nil)
>> are likely to be able to work out what is happening, while someone who
>> accidentally writes
>> (wanted-mode)
>> and later
>> (wanted-mode)
>> has a more pernicuous problem.
>
> So the toggling functions have been broken too!? Anyway I’d say most such
> users don’t write, they just click/touch.

Yes.


> Now do you mean that for emacs developers too, unlearned user mistakes driven
> interfacing has become the guiding principle? I use *n?x systems because I
> preferred to learn a few things from the start and then know what happens and
> get what I want. Now this is more and more difficult as the (supposed) average
> behaviour of occasional users rules (and constantly changes, as well as its
> perception by new developers). Users who need to work productively are getting
> nervous because they don’t have time to spend playing with their
> configurations at each new release of any piece of software. Breaking backward
> compatibility had always been a NONO, even at Microsoft.

Indeed, breaking backward-compatible is a negative thing. But, then,
fixing a bug also breaks backward-compatibility if your code depends on
it.

This is somewhere in between. I certainly used to do

(add-hook 'blah 'wanted-mode)

which generally works.

Then I found out about 

(add-hook 'blah 'turn-on-wanted-mode)

which works better. But many people did the former. Now it works
correctly as well.

I agree with you, that breaking backward-compatible is a bad thing. But
there are gains and losses to be weighed here. As Stefan says, they
thought about this before hand, and they looked to see how many cases of
"accidental nil" vs "deliberate nil" there are in practice. I understand
your irritation; but I don't understand why you can't seem to see that
it's a compromise that advantages many.

Phil