From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: feature request: indicator of minibuffer-recursion depth Date: Sat, 16 Jun 2007 07:36:12 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1182004663 31937 80.91.229.12 (16 Jun 2007 14:37:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 16 Jun 2007 14:37:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Juanma Barranquero" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 16 16:37:41 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HzZPI-0002cF-RS for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2007 16:37:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzZPI-0000UE-9H for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2007 10:37:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HzZPE-0000U9-Ko for emacs-devel@gnu.org; Sat, 16 Jun 2007 10:37:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HzZPD-0000Tw-4P for emacs-devel@gnu.org; Sat, 16 Jun 2007 10:37:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzZPC-0000Tt-TO for emacs-devel@gnu.org; Sat, 16 Jun 2007 10:37:34 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HzZPC-0004Oi-8A for emacs-devel@gnu.org; Sat, 16 Jun 2007 10:37:34 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l5GEbUTM015253; Sat, 16 Jun 2007 08:37:30 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5GE79RA009660; Sat, 16 Jun 2007 08:37:29 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-42.vpn.oracle.com by acsmt350.oracle.com with ESMTP id 2934120371182004584; Sat, 16 Jun 2007 07:36:24 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:73071 Archived-At: > 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. >=20 > 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.=20 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...) >=20 > 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=20 > > just provide the original source code, to "be *really* general".=20 > > Arbitrary generality is not the aim, in any case. Ease of use for=20 > > the target user audience is the aim. >=20 > And you're the target audience.=20 ? > 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=20 > > change. This is a _trivial_ change for users, provided you don't=20 > > make it unnecessarily hard to change - for most users. Losers = indeed. >=20 > 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.