[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: feature request: indicator of minibuffer-recursion depth
From: |
Drew Adams |
Subject: |
RE: feature request: indicator of minibuffer-recursion depth |
Date: |
Sat, 16 Jun 2007 07:36:12 -0700 |
> A few years ago, while discussing the help argument highlighting
> support, Richard said:
> > "To say that a user can customize something does not necessarily mean
> > introducing a defcustom to customize it. That is one of many
> > customization mechanisms in Emacs. Another customization mechanism is
> > to redefine a function.
I agree with that 100%. And?
> Some customizations are natural to do in that way, and some are
> important enough to be worth installing a defcustom for. But we
> should refuse to fall into thinking automatically "add a defcustom"
> whenever we think something might want to be changed by some users.
No one has argued that. Just as no one, including you so far, has argued that
we should _never_ add a defcustom when we think users might want to change
something, and instead we should _always_ expect them to redefine functions.
This is not about "always" and "never". As in all such cases, it's about
judgment, not catechism - there is no hardline rule that you can apply in all
cases.
People can judge differently. Richard will ultimately judge, and he might well
agree with you on this one. I sometimes disagree with Richard and I sometimes
agree with him - same as with anyone else. It is not because Richard said what
you quoted above that I adhere to it - exegesis doesn't persuade me - I agree
with it because I too think that Customize, like anything else, has its limits.
> > The first thing I did after getting Miles's code was to add a
> > defface and a defcustom to it.
>
> Judging by the prodigious amount of *+.el packages you produce, I tend
> to think this is the first thing you do with everyone's code... (I'm
> joking here, please don't take it personally.)
I don't take it personally; I don't even interpret it as a criticism, personal
or technical. Here is the logic behind that practice, in case you are
interested:
Miles posted that code as a snippet to emacs-devel. I expected that code to be
added to Emacs 22 (with Kim's 8.3 file renaming and possibly with some other
changes). That was the gist of the discussion here at that time.
In order that users besides those who read emacs-devel could benefit from it
before the release, I posted Miles's snippet to Emacs Wiki (with his name as
author) as mb-depth.el - the file name being talked about here at that time.
Rather than change that code directly, I provided a separate snippet that
improves it a bit for at least some users. I posted that snippet to the wiki
separately, under my name (only I am to blame for it). There are snippets of
enhancements to Emacs code all over the wiki - people use them or don't use
them, as they please. Some are posted as separate files for easy loading, some
are just pasted on Web pages and people copy them to their .emacs.
I named my snippet file mb-depth+.el for easy reference to the code it
enhances. Would you prefer a different file name? Would you prefer that I
didn't post the original at all? Would you prefer that I modified the original
directly? What would be your preference?
I was unable to supply patches directly at that time (or, rather, FSF was
unwilling to accept them, because of a lack of employer papers). I filed bugs.
I sometimes filed enhancement requests or suggested enhancements on
emacs-devel. I sometimes added enhancements to the wiki as separate *+.el or
*-.el files that I wanted to make available to users immediately (vs them
waiting until the next release or perhaps forever if the enhancement isn't
deemed of general use for Emacs itself).
I act similarly with libraries by others that are not part of Emacs: I write to
the authors, proposing my amendment or enhancement, saying that they can add it
to their library if they like (and that no attribution to me is needed). If I
cannot get a reply or the author doesn't want to add the enhancement to the
original library, and if I still think it can be useful, then I add it to the
wiki as a separate library, and I use my `+/-' file-name convention to make the
connection to the file it enhances. My convention uses `-' for a file to be
loaded before, and `+' for a file to be loaded after, the file to be enhanced.
That seems like a good approach, to me. What approach would you prefer that I
take, Juanma?
> I didn't propose making the thing non-customizable; only that the
> user who wants to do it takes the effort to use a little lisp.
> That's what .emacs was for, I thought.
Learn Lisp to change a color. Right.
Don't get me wrong - I am all in favor of encouraging Emacs users to learn
Lisp. And making them do so to be able to change the text or face used here
might help some of them to do that. But others will not learn Lisp for such a
minor preference change, and there is no good reason that they should not be
able to express their preference also.
> > people are passionate even about preferences that others think
> > of as perfectly silly. (Did I mention religious preferences? Oops...)
>
> Don't you thing that's a little over the top? Suddenly I'm
> ridiculizing people's religious beliefs?
No, I was hinting that _I_ might be doing so.
The point was that people care about things that might seem to others to be
only silly "tiny features". One person's silliness can be another person's
sacred object. (In traditional English, the expression would in fact be "sacred
cow", but that might offend someone - precisely in keeping with the spirit of
this point).
> > That's no more general than doing nothing - you might as well
> > just provide the original source code, to "be *really* general".
> > Arbitrary generality is not the aim, in any case. Ease of use for
> > the target user audience is the aim.
>
> And you're the target audience.
?
> People who can use customize and
> change the color is the target audience.
Yes. They are _part_ of the Emacs-user target audience. They too are Emacs
users or potential users.
> People who knows how to
> program, or that is not afraid of adding one line of lisp code to
> their .emacs is now not the target audience.
No one said that they are not also part of the target audience. Adding ease of
use for non-Lispers does not exclude Lispers. Your approach excludes non-Lisper
users. That's OK for some things, but it's not necessary for something as
simple as this. Even non-Lispers should be able to customize this tiny feature.
> > And this is something that is _not_ inherently difficult to
> > change. This is a _trivial_ change for users, provided you don't
> > make it unnecessarily hard to change - for most users. Losers indeed.
>
> Please, don't hesitate to write the defcustom that allows the
> customizations you want, and *also* the ones I want (including the
> ability to run a function). I swear I won't be opposed to it. You
> think it should be customizable, you do the effort.
I don't think it's a matter of measuring effort. I am not discounting your
effort.
- Re: feature request: indicator of minibuffer-recursion depth, (continued)
- Re: feature request: indicator of minibuffer-recursion depth, Andreas Röhler, 2007/06/16
- RE: feature request: indicator of minibuffer-recursion depth, Drew Adams, 2007/06/15
- Re: feature request: indicator of minibuffer-recursion depth, Juanma Barranquero, 2007/06/15
- RE: feature request: indicator of minibuffer-recursion depth, Drew Adams, 2007/06/15
- Re: feature request: indicator of minibuffer-recursion depth, Juanma Barranquero, 2007/06/15
- RE: feature request: indicator of minibuffer-recursion depth, Drew Adams, 2007/06/15
- Re: feature request: indicator of minibuffer-recursion depth, Juanma Barranquero, 2007/06/15
- RE: feature request: indicator of minibuffer-recursion depth, Drew Adams, 2007/06/16
- Re: feature request: indicator of minibuffer-recursion depth, Juanma Barranquero, 2007/06/16
- Re: feature request: indicator of minibuffer-recursion depth, Juri Linkov, 2007/06/16
- RE: feature request: indicator of minibuffer-recursion depth,
Drew Adams <=
- Re: feature request: indicator of minibuffer-recursion depth, Richard Stallman, 2007/06/15
- Re: feature request: indicator of minibuffer-recursion depth, Juri Linkov, 2007/06/15
- Re: feature request: indicator of minibuffer-recursion depth, Juanma Barranquero, 2007/06/15
- Re: feature request: indicator of minibuffer-recursion depth, Juri Linkov, 2007/06/15
- Re: feature request: indicator of minibuffer-recursion depth, Juanma Barranquero, 2007/06/15
- Re: feature request: indicator of minibuffer-recursion depth, Juri Linkov, 2007/06/15
- Re: feature request: indicator of minibuffer-recursion depth, Juanma Barranquero, 2007/06/15
- Re: feature request: indicator of minibuffer-recursion depth, Richard Stallman, 2007/06/16