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: Honoring traditional defaults [was: Transient Mark Mode on bydefault] Date: Mon, 24 Mar 2008 15:47:38 -0700 Message-ID: <004d01c88e01$0f93b8f0$c2b22382@us.oracle.com> References: <87myopnj0l.fsf@stupidchicken.com> <20080324115510.GA1563@muc.de> <874pavg45t.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1206398921 8214 80.91.229.12 (24 Mar 2008 22:48:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Mar 2008 22:48:41 +0000 (UTC) To: "'Stephen J. Turnbull'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 24 23:49:11 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JdvTZ-0002Gw-C9 for ged-emacs-devel@m.gmane.org; Mon, 24 Mar 2008 23:49:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdvSy-0003Ix-BU for ged-emacs-devel@m.gmane.org; Mon, 24 Mar 2008 18:48:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JdvSu-0003Fx-8G for emacs-devel@gnu.org; Mon, 24 Mar 2008 18:48:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JdvSr-0003Ag-Ja for emacs-devel@gnu.org; Mon, 24 Mar 2008 18:48:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdvSr-0003AL-Aq for emacs-devel@gnu.org; Mon, 24 Mar 2008 18:48:25 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JdvSq-00065z-QG for emacs-devel@gnu.org; Mon, 24 Mar 2008 18:48:25 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m2OMmJfi002321; Mon, 24 Mar 2008 16:48:19 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m2O9wFrs000399; Mon, 24 Mar 2008 16:48:18 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3622243261206398857; Mon, 24 Mar 2008 15:47:37 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Mar 2008 15:47:37 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <874pavg45t.fsf@uwakimon.sk.tsukuba.ac.jp> Thread-Index: AciN+2iGDsPN8eBEQGCDUW3Y5eL5zgAAFQSA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:93344 Archived-At: > On the other hand, the "everything I need to know about Emacs I > learned in kindergarten" crowd *should* have a "revert to tradition" > customization available. Interesting. I first (mis)read that to mean newbies who just wanted to use Emacs (at least at first) in a way they were used to. IOW, I read the opposite of what you meant. By "revert to tradition", I at first thought you meant a newbie's idea of tradition, i.e. what s?he was used to. Then I read on, and saw what you really meant. It's interesting (and a bit ironic), because the same approach you propose for Emacs traditionalists to turn back the clock to a prior Emacs release (Please just make it work like before!) could also be used to provide alternative out-of-the-box experiences for Emacs newbies (and others). That is, provide one or more predefined sets of preference settings. Instead of the only customization possibility being to dive into the tangled swamp of Emacs's myriad options, users could choose a suitable macro-level option: a set of option settings. The individual low-level options already exist, and a suitable way (e.g. Options submenu) for users to choose a set of settings could easily be designed. The hard part might be agreeing on which such sets to provide. But assuming we could do that without too much trouble, I think it would be a good idea. Users could then choose among a few predefined Emacs "skins" (though it's more than skin deep) in, say, the Options menu. Each skin would make a bunch of settings, such as CUA selection mode, show/hide menus, toolbars, tooltips,..., whatever. Things that we think newbies might appreciate. And oldbies: Sets that correspond to the default Emacs behavior for previous releases (what you described) could be included. With the possibility of providing more than one skin, just which settings to use for each skin would be less of a big deal (fight). One of the available skins would be chosen as the default Emacs behavior. For now, at least, that default would have the default settings that Emacs already has. This would provide users with an easy rough cut, to let them quickly get something more or less suitable. Later, they could fine-tune preferences, like we all do. This could (1) give users a coarse-grain way to customize, (2) substitute for some of the here-newbie-start-with-my-dot-emacs that goes around, and perhaps (3) reduce some of the haggling here over what is TRT to start out with. The first task would be to create the infrastructure - something along the lines of what Stephen proposed. The second task would be to create the UI for choosing such a set (skin). The third task would be to decide on which sets of which settings to predefine. The tasks could be done in parallel, if we were sure to do all three. It would of course be possible for Lispy users and programs to extend the set of skins. Color themes are analogous (and a color theme could be a skin component). WDOT? > Then there would be a command `custom-set-all-to-prior-defaults' or > so, which would get a version from the user, defaulting to the prior > public release. Next, map over the alist of defaults accumulating the > most recent default prior to the user-specified version, if any. Call > this the "prior defaults alist". Now the command maps over the prior > defaults alist. If a variable appears as a key in the prior defaults > alist, and the user has a customization, we ignore it, and continue > with the next variable. If the user has no customization for the > variable, then we create one, setting the user's customization to the > prior default. > > Finally, it emits a warning telling the user which variables it > customized. > > If desired, there could also be a customizable variable for > determining how far back to turn the clock, something like > `emacs-version-for-prior-defaults'. Presumably Alan would set this to > "18.59" or so. This would be used instead of the "most recent > public release" as the default for `custom-set-all-to-prior-defaults'. > > IMO this handles changes in defaults with a minimum of annoyance to > those with a classical education while making it possible to change > defaults to something more friendly to the GUI generation. > > To be honest, I'm not interested in implementing this scheme at this > time, but if and when I get around to it, I'll post here. If somebody > decides to grab the ball and run with it, I'd appreciate the courtesy > of an email, though.