Theodore Tso <tytso@xxxxxxx> writes: > 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"? > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
