unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: "Alexandre Oberlin" <email_via_web@migo.info>
To: help-gnu-emacs@gnu.org
Subject: Re: Why is it not possible to use "nil" any more in init files ?
Date: Tue, 25 Nov 2014 16:07:39 +0100	[thread overview]
Message-ID: <op.xpvyy1fofjdmwo@tournesol> (raw)
In-Reply-To: mailman.14534.1416923435.1147.help-gnu-emacs@gnu.org

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


--


  parent reply	other threads:[~2014-11-25 15:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-22 12:57 Why is it not possible to use "nil" any more in init files ? Alexandre Oberlin
2014-11-22 14:37 ` Stefan Monnier
     [not found] ` <mailman.14325.1416667223.1147.help-gnu-emacs@gnu.org>
2014-11-25 13:19   ` Alexandre Oberlin
2014-11-25 13:50     ` Phillip Lord
2014-11-25 14:22     ` Stefan Monnier
     [not found]     ` <mailman.14536.1416925359.1147.help-gnu-emacs@gnu.org>
2014-11-25 16:10       ` Alexandre Oberlin
2014-11-26 14:18         ` Phillip Lord
     [not found]         ` <mailman.14663.1417011535.1147.help-gnu-emacs@gnu.org>
2014-11-26 14:39           ` Alexandre Oberlin
2014-11-26 21:12           ` Alexandre Oberlin
2015-01-19 10:31       ` WJ
2015-01-19 14:38         ` Stefan Monnier
     [not found]         ` <mailman.18143.1421678302.1147.help-gnu-emacs@gnu.org>
2015-01-19 14:56           ` Rusi
     [not found]     ` <mailman.14534.1416923435.1147.help-gnu-emacs@gnu.org>
2014-11-25 15:07       ` Alexandre Oberlin [this message]
2014-11-26 14:15         ` Phillip Lord
     [not found]         ` <mailman.14661.1417011326.1147.help-gnu-emacs@gnu.org>
2014-11-26 20:45           ` Alexandre Oberlin
2014-11-27  3:00             ` Stefan Monnier
2015-01-20  1:03       ` WJ
2015-01-21  6:50         ` Thien-Thi Nguyen
2014-11-25 15:07 ` Emacs User

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.xpvyy1fofjdmwo@tournesol \
    --to=email_via_web@migo.info \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).