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

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

[Alexandre Oberlin]

Hello everyone,


I was somewhat forced to upgrade from emacs 23 to 24 (23 would not start  
after some Debian upgrading).
Then in emacs 24 the command (tool-bar-mode nil) in my .emacs was  
understood as if I do want a toolbar...

I know that departing from proven approaches for no sensible reason is top  
of the art but is there any kind of other rationale to make the thing not  
backward-compatible?


Cheers,


Alexandre

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

[Stefan Monnier]

> I know that departing from proven approaches for no sensible reason is top
> of the art but is there any kind of other rationale to make the thing not
> backward-compatible?

Of course, there's a reason: All minor modes since Emacs-23 (IIRC)
should turn themselves ON when called with a nil argument, so you don't
need turn-on-FOO-mode and you can just say:

   (add-hook 'bar-mode-hook 'foo-mode)

The better part of this incompatible change is that it silently *fixed*
many people's .emacs since many people already used:

   (add-hook 'bar-mode-hook 'foo-mode)

without realizing that this could actually turn the mode OFF in
some cases.


        Stefan

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

[Alexandre Oberlin]

Thanks Stefan for this explanation. So IIUC that trick broke some correct  
.emacs in order to magically fix some broken ones?

Alexandre


On Sat, 22 Nov 2014 15:37:04 +0100, Stefan Monnier  
<monnier@iro.umontreal.ca> wrote:

>> I know that departing from proven approaches for no sensible reason is  
>> top
>> of the art but is there any kind of other rationale to make the thing  
>> not
>> backward-compatible?
>
> Of course, there's a reason: All minor modes since Emacs-23 (IIRC)
> should turn themselves ON when called with a nil argument, so you don't
> need turn-on-FOO-mode and you can just say:
>
>    (add-hook 'bar-mode-hook 'foo-mode)
>
> The better part of this incompatible change is that it silently *fixed*
> many people's .emacs since many people already used:
>
>    (add-hook 'bar-mode-hook 'foo-mode)
>
> without realizing that this could actually turn the mode OFF in
> some cases.
>
>
>         Stefan
>
>


--

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

[Phillip Lord]

Clearly, if the interface has changed it runs the risk of breaking some
statements which were previously fulfilling the programmers intent.
This, of course, is irritating for those affected, but that doesn't make
it wrong.

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.

I always used

(hated-mode 0)

which seems to be more intuitive than passing nil. Perhaps this is why
the change did not irritate me.


Alexandre Oberlin <email_via_web@migo.info> writes:

> Thanks Stefan for this explanation. So IIUC that trick broke some correct
> .emacs in order to magically fix some broken ones?
>
> Alexandre
>
>
> On Sat, 22 Nov 2014 15:37:04 +0100, Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
>
>>> I know that departing from proven approaches for no sensible reason is top
>>> of the art but is there any kind of other rationale to make the thing not
>>> backward-compatible?
>>
>> Of course, there's a reason: All minor modes since Emacs-23 (IIRC)
>> should turn themselves ON when called with a nil argument, so you don't
>> need turn-on-FOO-mode and you can just say:
>>
>>    (add-hook 'bar-mode-hook 'foo-mode)
>>
>> The better part of this incompatible change is that it silently *fixed*
>> many people's .emacs since many people already used:
>>
>>    (add-hook 'bar-mode-hook 'foo-mode)
>>
>> without realizing that this could actually turn the mode OFF in
>> some cases.
>>
>>
>>         Stefan
>>
>>
>
>
> --
>
>

-- 
Phillip Lord,                           Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

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

[Stefan Monnier]

> Thanks Stefan for this explanation.  So IIUC that trick broke some correct
> .emacs in order to magically fix some broken ones?

Yup, and not just for .emacs files but also for calls made from one
package to another.  Basically, experience shows that *toggling* is
very rarely what we want when writing the Elisp code.

99.9% of calls of the form (foo-mode nil) or (foo-mode) either were
meant to enable the mode (the vast majority), or were meant to disable
the mode (a minority, but not an insignificant one).

A small proportion of those calls were correct (because the context
made sure that the mode was always either enabled or disabled), but
after yet-another bug report of someone not understanding why his
font-lock was not enabled in such and such circumstance, I decided that
it was time to break the small proportion of those minority cases which
expected (and with reason) the call to disable the mode.

This change was made more than 5 years ago, and it hasn't caused much of
a ruckus and even fewer bug reports, so I think I made the right call.


        Stefan

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

[Emacs User]

> Then in emacs 24 the command (tool-bar-mode nil) in my .emacs was  
> understood as if I do want a toolbar...

I wonder if this is related to

when I'm already in text fill mode, M-x toggle-text-mode-auto-fill turns it
on although it's already on, and I have to issue the command again...

Is there one command to turn it off given it's already on? I don't know how
long I have been seeing this but it is certainly happening in 24.2.1.

Bill

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

[Alexandre Oberlin]

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.

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.

IMHO this "intuitive" paradigm is OK for phones/tablets, at least if some  
consensus can be found. And we all know that casual users will more and  
more use phones/tablets, not computers any more. As for the more motivated  
users, they should rather be helped with some good principles and  
tutorials, and not the developers adapt to their initial shortcomings.

Cheers,


Alexandre



On Tue, 25 Nov 2014 14:50:22 +0100, Phillip Lord  
<phillip.lord@newcastle.ac.uk> wrote:

>
> Clearly, if the interface has changed it runs the risk of breaking some
> statements which were previously fulfilling the programmers intent.
> This, of course, is irritating for those affected, but that doesn't make
> it wrong.
>
>> 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.
>
> I always used
>
> (hated-mode 0)
>
> which seems to be more intuitive than passing nil. Perhaps this is why
> the change did not irritate me.
>
>
> Alexandre Oberlin <email_via_web@migo.info> writes:
>
>> Thanks Stefan for this explanation. So IIUC that trick broke some  
>> correct
>> .emacs in order to magically fix some broken ones?
>>
>> Alexandre
>>
>>
>> On Sat, 22 Nov 2014 15:37:04 +0100, Stefan Monnier  
>> <monnier@iro.umontreal.ca>
>> wrote:
>>
>>>> I know that departing from proven approaches for no sensible reason  
>>>> is top
>>>> of the art but is there any kind of other rationale to make the thing  
>>>> not
>>>> backward-compatible?
>>>
>>> Of course, there's a reason: All minor modes since Emacs-23 (IIRC)
>>> should turn themselves ON when called with a nil argument, so you don't
>>> need turn-on-FOO-mode and you can just say:
>>>
>>>    (add-hook 'bar-mode-hook 'foo-mode)
>>>
>>> The better part of this incompatible change is that it silently *fixed*
>>> many people's .emacs since many people already used:
>>>
>>>    (add-hook 'bar-mode-hook 'foo-mode)
>>>
>>> without realizing that this could actually turn the mode OFF in
>>> some cases.
>>>
>>>
>>>         Stefan
>>>
>>>
>>
>>
>> --
>>
>>
>


--

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

[Alexandre Oberlin]

Toggling functions are obviously not always suitable for config files or  
scripts, though there are situations where they simplify code.

Toggling functions remain quite convenient on the command line, with the  
new state displaying in the minibuffer, and I am glad to see that this has  
been respected. Now IMHO, it is fundamental that toggling functions like  
all functions behave the same when called from a file or interactively.  
They could maybe report a warning in the former case, but trigger a  
revolution and create unending and potentially serious problems in legacy  
code? How many million users had reported to have trouble with such  
functions in scripts? Were they not able to learn good principles?

On top of that, not having the explicit arguments work as once expected  
does not help. Really, ain’t it a bit confusing to have
(cua-mode -1)
return nil and
(cua-mode nil)
return t ?


Downgrading ASAP,


Alexandre


-- 
In the long run, every program becomes rococco, and then rubble.
		Alan Perlis

>> Thanks Stefan for this explanation.  So IIUC that trick broke some  
>> correct
>> .emacs in order to magically fix some broken ones?
>
> Yup, and not just for .emacs files but also for calls made from one
> package to another.  Basically, experience shows that *toggling* is
> very rarely what we want when writing the Elisp code.
>
> 99.9% of calls of the form (foo-mode nil) or (foo-mode) either were
> meant to enable the mode (the vast majority), or were meant to disable
> the mode (a minority, but not an insignificant one).
>
> A small proportion of those calls were correct (because the context
> made sure that the mode was always either enabled or disabled), but
> after yet-another bug report of someone not understanding why his
> font-lock was not enabled in such and such circumstance, I decided that
> it was time to break the small proportion of those minority cases which
> expected (and with reason) the call to disable the mode.
>
> This change was made more than 5 years ago, and it hasn't caused much of
> a ruckus and even fewer bug reports, so I think I made the right call.
>
>
>         Stefan
>
>


--

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

[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

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

[Phillip Lord]

Alexandre Oberlin <email_via_web@migo.info> writes:
> On top of that, not having the explicit arguments work as once expected does
> not help. Really, ain’t it a bit confusing to have
> (cua-mode -1)
> return nil and
> (cua-mode nil)
> return t ?

Only if you actually do this. For instance,

(cua-mode -1)
(cua-mode 1)

works just fine and as expected.

Or even 

(cua-mode 0)
(cua-mode 1)

Bottom line is that nil in lisp is overloaded. In this case,
it means both "explicit false" and "no argument supplied".

Life is a compromise, nil double so.

Phil

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

[Alexandre Oberlin]

Hello,

On Wed, 26 Nov 2014 15:18:42 +0100, Phillip Lord  
<phillip.lord@newcastle.ac.uk> wrote:

> Bottom line is that nil in lisp is overloaded. In this case,
> it means both "explicit false" and "no argument supplied".
>
> Life is a compromise, nil double so.
I never had a single nil-related problem in various Lisp’s I have been  
using ... until now.

Alexandre

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

[Alexandre Oberlin]

On Wed, 26 Nov 2014 15:15:12 +0100, Phillip Lord  
<phillip.lord@newcastle.ac.uk> wrote:

> 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.
Looks like there is a huge difference with the new minor mode setting  
issue: the above adds clarity and does not break any backward  
compatibility, so it is a good move, just like x-get-selection should be  
be preferred to x-selection in new code, but x-selection still works.   
This approach of adding more specific and unambiguous function names  
without breaking anything could perfectly have been used for the mode  
setting issue.  Taking enriched-mode (which I use all the time) as an  
example, one could have added:
(set-enriched-mode) and (unset-enriched-mode)
while leaving the intrinsically ambiguous (enriched-mode) toggling as well  
in evaluation as interactively.

> I don't understand why you can't seem to see that
> it's a compromise that advantages many.
This reminds me of parents who don’t understand why they should be strict  
with their kid, when laxity brings contentment to the kid and peace to  
themselves... for some time ;-)


Cheers,

Alexandre

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

[Alexandre Oberlin]

On Wed, 26 Nov 2014 15:18:42 +0100, Phillip Lord  
<phillip.lord@newcastle.ac.uk> wrote:

> Bottom line is that nil in lisp is overloaded. In this case,
> it means both "explicit false" and "no argument supplied".
How could (too-bar-mode) and (tool-bar-mode nil) yield different results  
in emacs 23.4 then? Another nasty overloading is when nil is made  
practically equivalent to t in (tool-bar-mode nil).

Alexandre

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

[Stefan Monnier]

> This reminds me of parents who don’t understand why they should be strict
> with their kid, when laxity brings contentment to the kid and peace to
> themselves... for some time ;-)

For that reason, I decided to make the change despite knowing that it
would bring up complaints ;-)


        Stefan

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

[WJ]

Stefan Monnier wrote:

> 99.9% of calls of the form (foo-mode nil) or (foo-mode) either were
> meant to enable the mode (the vast majority), or were meant to disable
> the mode (a minority, but not an insignificant one).
> 
> A small proportion of those calls were correct (because the context
> made sure that the mode was always either enabled or disabled), but
> after yet-another bug report of someone not understanding why his
> font-lock was not enabled in such and such circumstance, I decided that
> it was time to break the small proportion of those minority cases which
> expected (and with reason) the call to disable the mode.

> 99.9% of calls of the form (foo-mode nil) or (foo-mode) either were
> meant to enable the mode (the vast majority), or were meant to disable
> the mode (a minority, but not an insignificant one).
> 
> A small proportion of those calls were correct (because the context
> made sure that the mode was always either enabled or disabled), but
> after yet-another bug report of someone not understanding why his
> font-lock was not enabled in such and such circumstance, I decided that
> it was time to break the small proportion of those minority cases which
> expected (and with reason) the call to disable the mode.


Passing nil as an argument is not the same as passing no arguments.
Don't you know how to tell the difference?

This won't work:

(defun foo (&optional arg)
  (print (if arg arg "no arg. given")))


This will work:

(defun foo (&rest args)
  (if args
    (message "arg. is %s" (car args))
    (message "no arg. given")))

: (foo)
no arg. given
: (foo nil)
arg. is nil


When mediocre programmers bow to the wishes of the most ignorant users,
the result is indeed sad.

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

[Stefan Monnier]

> When mediocre programmers

Thanks for the compliment,


        Stefan

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

[Rusi]

On Monday, January 19, 2015 at 8:08:24 PM UTC+5:30, Stefan Monnier wrote:
> > When mediocre programmers
> 
> Thanks for the compliment,

HA HA

Authors of emacs are dumb
Author of "Ninth symphony" was deaf

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

[WJ]

Phillip Lord wrote:

> I always used
> 
> (hated-mode 0)
> 
> which seems to be more intuitive than passing nil.

No, it doesn't.

We are not dealing with C or Forth.

In Lisp and Scheme, as a truth value, 2 is the same as
1 and the same as 0.  The only thing that is false is
nil (in Scheme, #f).

What if, to the most mindless of users,
2+2=5 seemed more "intuitive" than 2+2=4.

Should elisp be changed so that (+ 2 2) will yield
5?  Or should the mindless be required to learn to think?

Rewarding the mindless and penalizing the thoughtful is
a monstrous thing to do.

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

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

() "WJ" <w_a_x_man@yahoo.com>
() Tue, 20 Jan 2015 01:03:48 +0000 (UTC)

   Rewarding the mindless and penalizing the thoughtful is
   a monstrous thing to do.

Well then apologies in advance for being monstrous:

 i thought i thought i knew i knew,
 i knew i knew i thought i thought
 right from wrong, false from true,
 what is to be, what could be not.

 then M-x zone and now grows a doubt:
 where is the monster, w/in or w/out?

"C is is for cookie and cookie is for me!"

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]