unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'Miles Bader' <miles@gnu.org>, 'Emacs-Devel devel' <emacs-devel@gnu.org>
Subject: RE: `set-variable' should use :set
Date: Fri, 22 Oct 2010 16:17:29 +0900	[thread overview]
Message-ID: <8762wulmra.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <823F3463F14A490A90A6075368296AC2@us.oracle.com>

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.




  reply	other threads:[~2010-10-22  7:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-21 17:25 `set-variable' should use :set Drew Adams
2010-10-22  0:34 ` Miles Bader
2010-10-22  0:48   ` Miles Bader
2010-10-22  1:11     ` Drew Adams
2010-10-22  2:20       ` Stephen J. Turnbull
2010-10-22  4:34         ` Drew Adams
2010-10-22  7:17           ` Stephen J. Turnbull [this message]
2010-10-22  8:29             ` David Kastrup
2010-10-22 10:43           ` Juanma Barranquero
2010-10-22 13:40             ` Drew Adams
2010-10-22 14:02               ` David Kastrup
2010-10-22 22:42               ` Juanma Barranquero
2010-10-23  4:48                 ` Stephen J. Turnbull
2010-10-23 16:13                   ` Drew Adams
2010-10-23 17:47                     ` Juanma Barranquero
2010-10-23 18:44                       ` Glenn Morris
2010-10-23 19:01                       ` Jambunathan K
2010-10-24 16:15                       ` Chong Yidong
2010-10-22 14:01           ` Stefan Monnier
2010-10-22 16:03             ` Drew Adams
2010-10-22  7:42         ` Eli Zaretskii
2010-10-22  7:39       ` Eli Zaretskii
2010-10-22  8:16         ` Stephen J. Turnbull
2010-10-22  9:46           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8762wulmra.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=miles@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).