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 onbydefault] Date: Tue, 25 Mar 2008 00:21:45 -0700 Message-ID: <004501c88e48$e2365460$0600a8c0@us.oracle.com> References: <87myopnj0l.fsf@stupidchicken.com><20080324115510.GA1563@muc.de><874pavg45t.fsf@uwakimon.sk.tsukuba.ac.jp><004d01c88e01$0f93b8f0$c2b22382@us.oracle.com> <87tzive5r4.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 1206429827 15438 80.91.229.12 (25 Mar 2008 07:23:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Mar 2008 07:23:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stephen J. Turnbull'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 25 08:24:17 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 1Je3W4-0007G1-Kb for ged-emacs-devel@m.gmane.org; Tue, 25 Mar 2008 08:24:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Je3VT-0006wn-7K for ged-emacs-devel@m.gmane.org; Tue, 25 Mar 2008 03:23:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Je3VP-0006wY-0m for emacs-devel@gnu.org; Tue, 25 Mar 2008 03:23:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Je3VM-0006wM-HG for emacs-devel@gnu.org; Tue, 25 Mar 2008 03:23:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Je3VM-0006wJ-Bp for emacs-devel@gnu.org; Tue, 25 Mar 2008 03:23:32 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Je3VL-000638-RR for emacs-devel@gnu.org; Tue, 25 Mar 2008 03:23:32 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Je3VL-0000k1-21 for emacs-devel@gnu.org; Tue, 25 Mar 2008 03:23:31 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m2P7NR7m022036; Tue, 25 Mar 2008 02:23:27 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m2P5o2SQ019736; Tue, 25 Mar 2008 01:23:26 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3624493461206429705; Tue, 25 Mar 2008 00:21:45 -0700 Original-Received: from dradamslap1 (/141.144.72.71) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Mar 2008 00:21:44 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87tzive5r4.fsf@uwakimon.sk.tsukuba.ac.jp> Thread-Index: AciONy7TCFaUFUNlTc+zo7TbaJ8dCgAD8t9w 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 mx20.gnu.org: Linux 2.4-2.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:93393 Archived-At: > > 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). > > It is not that easy, and the proof is trivial: "Please make it work > like before" is a well-defined specification. "Provide alternative > experiences" is not, as the moribund "custom themes" stuff shows. To define a given set of settings, we do not need a well-defined specification. We need only (1) decide on the mechanism for implementing sets of settings and (2) agree on the settings to set and their values. For options and faces, applying custom-set-variables to an options alist and similarly for custom-set-faces could be enough for #1. Some customization can be more complex than setting options and faces, but it's not clear yet that we need any predefined "skins" that provide such complex customizations. Wrt #2: Individual preference sets do not need to set the same settings. Any set of preferences is a candidate for consideration.