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: turn-on-*-mode Date: Tue, 16 May 2006 08:16:50 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1147793400 6126 80.91.229.2 (16 May 2006 15:30:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 16 May 2006 15:30:00 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 16 17:29:55 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 1Fg1IY-0001k6-PH for ged-emacs-devel@m.gmane.org; Tue, 16 May 2006 17:17:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fg1IY-0000PT-1B for ged-emacs-devel@m.gmane.org; Tue, 16 May 2006 11:17:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fg1IE-0000Lb-MU for emacs-devel@gnu.org; Tue, 16 May 2006 11:17:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fg1ID-0000KY-0a for emacs-devel@gnu.org; Tue, 16 May 2006 11:17:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fg1IC-0000KT-Qk for emacs-devel@gnu.org; Tue, 16 May 2006 11:17: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 1Fg1Kr-0004e1-0G for emacs-devel@gnu.org; Tue, 16 May 2006 11:19:45 -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 k4GFGuZK007460 for ; Tue, 16 May 2006 10:16:57 -0500 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-73-26.vpn.oracle.com [141.144.73.26]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k4GFGtwB028387 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 16 May 2006 09:16:56 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 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:54582 Archived-At: We could even make a M-x toggle command which could toggle any mode (it should provide a list of known modes as completion choices). That would also be a good way to learn about new modes. It might even toggle any boolean variable given a C-u prefix... after the release! I suggested such a generic toggle with completion a while back - see thread "add generic toggle, turn on,and turn off commands to Options menu" (2006-03-04 and 2006-04-21-24). This also proposed adding such a generic toggle to the Options menu, since that menu cannot accomodate an unlimited number of specific toggle items. Richard's decision was this: I don't like the idea of a generic toggle menu item. I don't think that is a helpful UI. I don't have time to discuss it, though. Of course, the idea of a generic toggle command need not be coupled with the suggestion to add it to the Options menu. If the idea of such a command (but not menu item) is still open (Richard?), then please see the previous thread for some suggestions about treating quasi-binary options, that is, options that are essentially binary but whose non-nil value need not be t. Toggling a mode generically (your suggestion) is not necessarily the same as toggling a user option generically, and mode-variable values are not always nil and non-nil. But in many cases the treatment of the two could be the same or similar. In any case, any discussion of one should perhaps also consider the other. FATHOC (For after the release, of course.)