From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: scroll-down with pixel transition Date: Fri, 21 Apr 2017 08:47:48 -0700 (PDT) Message-ID: <1d41a3df-96bc-443c-8a7b-6e0faac46f37@default> References: <693E1D44-797B-4B0D-9D0B-6FEB6DF32531@misasa.okayama-u.ac.jp> <83lgqze7mq.fsf@gnu.org> <20170419.212155.180931830.tkk@misasa.okayama-u.ac.jp> <83a87ccv8s.fsf@gnu.org> <834lxkcssf.fsf@gnu.org> <834lxib7jy.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1492789732 15903 195.159.176.226 (21 Apr 2017 15:48:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Apr 2017 15:48:52 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 21 17:48:48 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d1ane-0003zx-6y for ged-emacs-devel@m.gmane.org; Fri, 21 Apr 2017 17:48:46 +0200 Original-Received: from localhost ([::1]:60284 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1ank-00030X-3B for ged-emacs-devel@m.gmane.org; Fri, 21 Apr 2017 11:48:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d1amr-0002yH-IQ for emacs-devel@gnu.org; Fri, 21 Apr 2017 11:47:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d1amn-0006DE-II for emacs-devel@gnu.org; Fri, 21 Apr 2017 11:47:57 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:19607) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d1amn-0006Cp-7i for emacs-devel@gnu.org; Fri, 21 Apr 2017 11:47:53 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3LFlpLo008025 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 21 Apr 2017 15:47:51 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3LFloJw005518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 21 Apr 2017 15:47:51 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3LFloBY006552 for ; Fri, 21 Apr 2017 15:47:50 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214191 Archived-At: > >> Our convention is to end user option names in '-flag', when they > >> are for users to set. Let's document that, if it isn't already. +1 Except that the criterion should not be "when they are for users to set". All user options are for users to set. Perhaps you didn't mean that, but you meant only names of Boolean options? (Your later mention of "t-or-nil" suggests that.) > > It is not currently documented in code conventions. >=20 > I think it used to be there, but I demoted it to: >=20 > @item @dots{}-flag > The value is significant only as to whether it is @code{nil} or not. > Since such variables often end up acquiring more values over time, > this convention is not strongly recommended. That's not a strong reason, IMO. Lots of things change over time, and if we want helpful names then we update the names as needed, accordingly. Yes, any name is a stake in the sand, and change can erode its relevance. But that's not a reason not to use helpful names. Otherwise, we'd always use names that have no special meaning (`x', `y', 'z'), to ensure maximum space for possible changes in meaning. I understand completely the problem of having a Boolean option `foo-flag' evolve to an option where certain non-nil values have special meaning (it is no longer strictly Boolean, or even perhaps vaguely Boolean). That's life. A name change at that point lets users know about the behavior change. And in some cases a name change is not needed - when, for example, all of the non-nil behaviors have a major behavior in common, and that behavior is the main raison d'etre for the option. IOW, if it is still essentially a Boolean, but there are some additional behavior differences, we might want to keep the suffix `-flag'. It's a judgment call. Here's an example - you might argue whether `-flag' is appropriate here, but the point is that non-nil means use WYSIWYG display and nil does not. (Evolution was not involved here, in fact - it was like this at the outset. But it could have evolved to this from a simple t/nil choice.) (defcustom icicle-WYSIWYG-Completions-flag "MMMM" "*Non-nil means show candidates in `*Completions*' using WYSIWYG. ...the particular non-nil value determines the appearance: * If t, the candidate displays its meaning: WYSIWYG. * If a string, the string is propertized and then appended to the candidate, to serve as a color swatch." :group 'Icicles-Completions-Display :type '(choice (string :tag "Show candidate plus a WYSIWYG swatch with text..." :value "MMMM") (const :tag "Show candidate itself using WYSIWYG" t) (const :tag "Show candidate as is, with no text properties" nil))) An alternative to such a naming convention, though it too is imperfect, is to use a test - something like this: (defun custom-type (variable) (and (custom-variable-p variable) (get variable 'custom-type))) In my code (Icicles), there is a command that lets you toggle Boolean options. By default, the only options you can do this to are those whose `custom-type' is `boolean'. But with a prefix argument you can also toggle options that are effectively Boolean, such as the one above. (`nil' is always toggled to `t' by this command, but there are other commands that cycle specific options among the possible values or that remember the last non-nil value and toggle `nil' back to it.) The point is that in Emacs "Boolean", and so `-flag', can mean something less strict than `t' vs `nil', and it can help users if we provide easy ways to use more or less strict interpretation - au choix - of whether a variable is Boolean. > In my experience, using FOO instead of FOO-flag is a better choice. Does this boil down to the reason given in the doc (above) that you wrote when you made the policy change? Or is there some additional reason? > Also, many boolean config variables can be introduced as minor > modes (in which case their name should end in "-mode"). Clearly that's not a relevant argument against the convention, since `*-mode' minor-mode variables are also necessarily Boolean. On the contrary: `*-flag' vs `*-mode' makes clear that the former is not associated with a minor mode.