Theodore Tso <tytso@mit.edu> writes:

quoted text
> To use a GNU emacs example, consider M-x customize, which is this
> huge, very fancy, *very* complex hierarchical mechanism with a
> pointy-clicky interface for setting options.  Most emacs experts
> wouldn't use it, preferring to open code raw emacs-lisp settings in
> their .emacs.el.  If you ask an old-time emacs user how to set up
> some specific feature setting via M-x customize, they might look at
> you blankly, because it's not an interface they use much, if at all.

Well, let me throw you back one of your questions: do you have any
statistics backing this up?

As to anecdotal evidence: I am an old-time Emacs user, and I pretty
much use customize _exclusively_ since it generally leaves me with a
_working_ configuration even when the DOC string might be sub-optimal
or misleading or hard to understand, and it makes sure that, say,
everything to make a global minor mode _active_ (like loading some
file, or calling some initialization functions) is done at the right
point of time.

If "old-time Emacs users" would not use customize, why would pretty
much _every_ package come with _working_ defcustoms?  Who writes and
_tests_ those defcustoms if not the "old-time Emacs users"?

quoted text
> A similar thing can be said of "git branch"; once you are familiar
> with how git works at a conceptual level, it can often be
> faster/easier to just hack the .git/config file directly, instead of
> using "git branch" to set up things the way you want.  And I'm
> pretty sure there are ways to set up the config file when you edit
> it by hand that you can't set up via "git branch".

Sure.  But we don't want to _require_ this sort of special knowledge
before one can even hope to do some basic task.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html