RE: feature request: indicator of minibuffer-recursion depth

[Drew Adams]

> 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.