gosh, stung by this bug. In my elisp code, i have:
this should turn it off, but actually it toggles.
here's a quote of its inline doc:
(recentf-mode &optional arg)
Toggle recentf mode.
With prefix argument arg, turn on if positive, otherwise off.
this is reproduciable in the following:
GNU Emacs 23.1.1 (i386-mingw-nt6.0.6002) of 2009-07-29 on SOFT-MJASON
GNU Emacs 18.104.22.168 (i386-mingw-nt6.0.6002) of 2009-06-30 on LENNART-69DE564 (patched)
On Aug 11, 9:05 pm, Kevin Rodgers
> Xah Lee wrote:
> >>> With prefix argument arg, turn on if positive, otherwise off.
> >> It's not clear whether nil is positive or negative.
> It seems clear to me that nil is not positive, so the "otherwise"
> condition holds.
> > Thanks. That's interesting.
> > Can the doc adds a warning like:
> > The argument should be a integer. Do not use t or nil.
> Do not use `supercalifragilisticexpialidocious' either.
> How about: Use nil to toggle the mode on or off.
i think that's a bit unreasonable.
the use of 1 and 0 for on and off for minor mode function, is not exactly intuitive, because in elisp, although the lang does not have boolean datatype, but by convention, t is for true, and nil for false, and technically, nil is false, everything else is true.
So, minor modes using 1 and 0 is kinda unclean, un-elegant, or counter intuitive. The reason it does that, is of course due to the fact that emacs commands thru interactive use by convention takes universal-argument, and universal-argument only take integer as arguments, not some string or lisp symbol. So, there's the justification for 1 and 0.
However, in lisp code, it is also reasonable to expect that nil would be equivalent to 0, as by lisp convention. This logic may not look logical to you, but i think is reasonable alternative expectation. When a mode gets its arg thru interactive use, the arg is expected to be integers by the way emacs do things interactively, and thus positive int is considered true or turn on, negative is considered false/off. But in lisp code, besides 1 and 0, you can also specify t and nil as usual by lisp convention. This could easily be considered as a alternative design decision.
(adding to the mess is that some command will change behavior as kinda on/off or true/false depending on whether universal-argument is called regardless of its argument)
all things considered, i think it is reasonable that a average lisp coder will be confused by this. Thus my recommendation that a warning or notes be added to the doc. Is there somewhere in elisp manual that explicitly explains/warns that commands that turn minor mode on/off stick to 1 and 0 and consider t and nil not acceptable argument?
PS i didn't receive your previous email, i just happened to see your reply in google group. I'm not much in the emacs dev community so i'm not regular gnu emacs bug database reader... please cc me too on this. thanks.
this is documented in emacs lisp manual.
• Minor Mode Conventions - GNU Emacs Lisp Reference Manual
thanks to Drew Adams and others: