From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xah Lee Newsgroups: gmane.emacs.bugs Subject: Re: bug#4102: 23.1.50; recentf-mode nil but toggles Date: Wed, 12 Aug 2009 12:33:43 -0700 (PDT) Organization: http://groups.google.com Message-ID: <26d7a64b-c393-42b9-bacf-8a9e6c62eadd@f20g2000prn.googlegroups.com> References: <04855577A772452A99C5FBCB8078CE4D@xahPC> <2F116E10862F449E8FE250395BB55937@xahPC> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1250130776 28683 80.91.229.12 (13 Aug 2009 02:32:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2009 02:32:56 +0000 (UTC) To: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 13 04:32:49 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MbQ7V-0002fw-1v for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Aug 2009 04:32:49 +0200 Original-Received: from localhost ([127.0.0.1]:56180 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbQ7S-0006Nm-BN for geb-bug-gnu-emacs@m.gmane.org; Wed, 12 Aug 2009 22:32:46 -0400 Original-Path: news.stanford.edu!newsfeed.stanford.edu!postnews.google.com!f20g2000prn.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.bug Original-Lines: 63 Original-NNTP-Posting-Host: 76.102.12.87 Original-X-Trace: posting.google.com 1250105623 16110 127.0.0.1 (12 Aug 2009 19:33:43 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Wed, 12 Aug 2009 19:33:43 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: f20g2000prn.googlegroups.com; posting-host=76.102.12.87; posting-account=bRPKjQoAAACxZsR8_VPXCX27T2YcsyMA User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.39 Safari/530.5, gzip(gfe), gzip(gfe) Original-Xref: news.stanford.edu gnu.emacs.bug:58253 X-Mailman-Approved-At: Wed, 12 Aug 2009 22:32:12 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:30142 Archived-At: On Aug 11, 9:05 pm, Kevin Rodgers wrote: > 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. hi Kevin, 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. Xah =E2=88=91 http://xahlee.org/ =E2=98=84