From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: add generic toggle, turn on, and turn off commands to Options menu Date: Fri, 21 Apr 2006 09:33:49 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1145637267 21548 80.91.229.2 (21 Apr 2006 16:34:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 21 Apr 2006 16:34:27 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 21 18:34:25 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FWyaJ-00037b-35 for ged-emacs-devel@m.gmane.org; Fri, 21 Apr 2006 18:34:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWyaI-0005E6-Im for ged-emacs-devel@m.gmane.org; Fri, 21 Apr 2006 12:34:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FWya5-0005BC-Do for emacs-devel@gnu.org; Fri, 21 Apr 2006 12:34:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FWya1-00057q-Co for emacs-devel@gnu.org; Fri, 21 Apr 2006 12:34:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FWya0-00057b-PJ for emacs-devel@gnu.org; Fri, 21 Apr 2006 12:34:00 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FWybb-0007WJ-35 for emacs-devel@gnu.org; Fri, 21 Apr 2006 12:35:39 -0400 Original-Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3LGXvDm001554 for ; Fri, 21 Apr 2006 11:33:57 -0500 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-66-230.vpn.oracle.com [141.144.66.230]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k3LGXtEb019770 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 21 Apr 2006 10:33:56 -0600 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:53198 Archived-At: Resending (and top-posting). The recent thread on "allout patch - more safe-local-variables, plus autoloads" reminded me of this, even though there is no real connection between the two. This is for after the release. 1. Many Emacs user options are quasi-binary: There is a primary behavior difference via nil vs non-nil, and a secondary one via different non-nil values. This is a common pattern. In addition, even those options that have only a nil vs non-nil behavior difference do not necessarily correspond to the custom type `boolean', which reflects only t vs nil. The `boolean' custom type represents perhaps a minority (?) of ~binary user options. A common custom type for quasi-binary options is a `choice' of nil and one or more other values. 2. It can be useful to toggle any of these various ~binary options, even though they don't all fit the standard toggling framework. When toggling a quasi-binary option to a non-nil value, of course, which non-nil value to use is up for grabs, but some general defaulting convention might be adopted, or the user could simply be queried for which non-nil value to use. As described in the original post, below, the user could use a prefix arg to determine the strictness of "binary" for toggling - this would determine the appropriate set of completion candidates. From strictest to laxest: a) only defcustom `boolean's; b) all defcustom `choice's between nil and a single other value; c) all defcustom `choice's that include nil; d) all user options; e) all variables. For the last two cases, "toggling" would not really mean toggling: it would just be setting the variable. But the next-to-last could use `defcustom' :type info to control the set of candidates. We might not want to differentiate between all of these gradations - in my proposal below I used only (a), (d), and (e). 3. The Options menu is handy for toggling binary user options. That menu is already large, however, and it is perhaps unreasonable to add all ~binary options to it. So far, we have made this choice of menu items at design time: we haggle over the choices in emacs-devel and then decide what is best for the user. 4. Something additional, not proposed below: Which options are most useful to have in the Options menu can depend on personal habits. We might define Options with a default set but make it easy for users to modify this interactively - that is, make the choice at runtime rather than design time. This could also be automatic: Emacs might keep track of which options a user changes most frequently, and adjust the Options menu accordingly. This is done, for example, with the MS Windows Start menu: it automatically reflects your use pattern, but you can also modify it manually (interactively), to always include particular items. Emacs does something similar with menus such as Buffers and Recent Files: they are updated dynamically. 5. Even with an Options menu that is thus tailored to personal use, it would be good for users to see readily which ~binary options are available (not just those in the menu) and to be able to toggle any of them easily. That is the reason for the proposal below: Provide a generic entry in the Options menu (and a generic command) for toggling all binary and quasi-binary options. The generic toggle would, by minibuffer completion, show users which ~binary options are available. It is by using the generic toggle (via menu or command) that Emacs would track your toggling and automatically accomodate the Options menu to your personal use (#4). 6. These two aspects of the proposal below can be separated: a) Add a generic toggling item to the Options menu (and add a generic toggling command). b) Try to accomodate quasi-binary options too wherever (or in some of the places where) we deal with truly binary options (either in the sense of nil vs non-nil or nil vs t). 7. Something additional, not proposed below: Save the current non-nil value, when toggling from a non-nil value to a nil value. That would be the value to restore when toggling back from nil to non-nil. For example, if you have a defcustom :type of (choice (const :tag "None" nil) regexp) and the current value is "foo.*", then toggling to nil would remember "foo.*" as the regexp to restore when toggling again. This would probably require some changes to the defcustom code. 8. The proposal below also suggests adding generic Turn On and Turn Off items to the Options menu. WDOT? ----------- For after the Release or Godot, whichever comes first - The question has occasionally been debated here whether such and such an option merits a place on the Options menu, and, if so, where to put it (submenu? order?). There are potentially lots and lots of boolean options that could be added to the menu, but it also makes sense to keep the menu a reasonable size. Here's a suggestion that might mitigate the effect of leaving some options out: As a fallback, add a generic menu item that reads the name of a binary option and toggles its value. In fact, add three generic menu items, to 1) toggle, 2) turn on, and 3) turn off any boolean option. In my own code I use such commands, which are also in the Options menu. And because many options are only "quasi-binary", you can use a prefix arg to control how strict the interpretation of "binary" is, for purposes of defining the set of completion candidates. Here's the doc string of the toggle-option command: Toggle option's value. This makes sense for binary (toggle) options. By default, completion candidates are limited to user options that have `boolean' custom types. However, there are many "binary" options that allow other non-nil values than t. You can use a prefix argument to change the set of completion candidates, as follows: - With a non-negative prefix arg, all user options are candidates. - With a negative prefix arg, all variables are candidates. Would this be useful?