From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: RE: `set-variable' should use :set Date: Fri, 22 Oct 2010 16:17:29 +0900 Message-ID: <8762wulmra.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87d3r3qd44.fsf@catnip.gol.com> <871v7jqchc.fsf@catnip.gol.com> <033D7FA139144B03B1370B9E9C1113ED@us.oracle.com> <87bp6nklx2.fsf@uwakimon.sk.tsukuba.ac.jp> <823F3463F14A490A90A6075368296AC2@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1287732788 9495 80.91.229.12 (22 Oct 2010 07:33:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 22 Oct 2010 07:33:08 +0000 (UTC) Cc: 'Miles Bader' , 'Emacs-Devel devel' To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 22 09:33:06 2010 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.69) (envelope-from ) id 1P9C7d-0005zW-78 for ged-emacs-devel@m.gmane.org; Fri, 22 Oct 2010 09:33:05 +0200 Original-Received: from localhost ([127.0.0.1]:47781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9C7b-00005A-5h for ged-emacs-devel@m.gmane.org; Fri, 22 Oct 2010 03:33:03 -0400 Original-Received: from [140.186.70.92] (port=47969 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9C73-0008W8-4n for emacs-devel@gnu.org; Fri, 22 Oct 2010 03:32:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P9C72-0000lf-3f for emacs-devel@gnu.org; Fri, 22 Oct 2010 03:32:29 -0400 Original-Received: from [130.158.254.170] (port=58543 helo=dmail01.cc.tsukuba.ac.jp) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P9C71-0000l4-L0; Fri, 22 Oct 2010 03:32:28 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (unknown [130.158.254.130]) by dmail01.cc.tsukuba.ac.jp (Postfix) with ESMTP id 5B957E04F5; Fri, 22 Oct 2010 16:15:59 +0900 (JST) Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 37C872AF544; Fri, 22 Oct 2010 16:15:46 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id 288FF2AF542; Fri, 22 Oct 2010 16:15:46 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 2654B3FA0512; Fri, 22 Oct 2010 16:15:46 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1BA9D1A3C36; Fri, 22 Oct 2010 16:17:29 +0900 (JST) In-Reply-To: <823F3463F14A490A90A6075368296AC2@us.oracle.com> X-Mailer: VM 8.1.93a under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:131969 Archived-At: Drew Adams writes: > That last part is a bit presumptuous, IMHO. Perhaps it means to > say only that `set-variable' is largely obsolete (although I don't > see why it would be - it is quick; Customize is not). You've simply identified an optimization that isn't premature. Congratulations! OK, point made. But I don't really understand why customize-variable needs to be any slower than set-variable. > ("Obsolete" is not a verb BTW (e.g. "obsoleted"), although it is > true that you can verb any noun.) Don't tell me that, submit a patch. ;-) > > I'm curious, what are your use cases? > > As I said before, more or less the same use cases as using Customize to set a > value (without saving it): That's not a use case. Which variables? As I wrote, I don't see a need for this, but maybe I just don't mess with the same variables that you do. > Also, I don't necessarily treat user options as things to be set > once in a blue moon and persist. Well, neither do I. For example, I might toggle debug-on-error or debug-on-signal a dozen times in a session. But since I do, those toggles live on C-c D E and C-c D S respectively, along with a number of other debugging utilities I use frequently in the C-c D keymap. set-variable kind of pales in comparision. OTOH, if I do something infrequently enough that I'd forget the key sequence I bound it to, customize-variable would do the trick. So it sounds to me like you must do a lot of experimenting with various options, and in that context I can see where set-variable would hit a sweet spot. I have no objection to you writing -- and maintaining -- variable-interactive declarations for any variables you care to, but I ain't gonna do it myself unless there's a lot more support for it from typical users. > I even proposed that Emacs allow for (i.e., optionally) typing > non-option vars. That suggestion was summarily dismissed by you - > the sole responder, with the single word "YAGNI". > http://lists.gnu.org/archive/html/emacs-devel/2009-10/msg00668.html > > We have different views of Emacs and its features. That's OK. > YAGNI. But IUI. That's not true, though. Maybe YWUI, but you admitted in that post that you have no implementation and don't intend to create one, and evidently even less intention to maintain a few thousand variable-interactive or type declarations. And that's the rub. If (as you suggest) set-variable could be made to use Customize descriptions without losing its speed, that would be reasonable. But duplicating the effort makes no sense. Similarly, the typing code clashes with the (alleged) intent of Emacs Lisp to be lightweight (at least compared to Common Lisp). So while your suggestions have merit in themselves, I don't see them fitting with Emacs philosophy very well.