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: Rename `mini-' options Date: Sat, 16 May 2009 12:21:55 -0700 Message-ID: <002601c9d65b$937ef9b0$0200a8c0@us.oracle.com> References: <26694.128.165.0.81.1242438439.squirrel@webmail.lanl.gov><002f01c9d5cb$9fd36b00$0200a8c0@us.oracle.com><003001c9d5ce$a044ea20$0200a8c0@us.oracle.com><873ab5fsyu.fsf@uwakimon.sk.tsukuba.ac.jp><87r5yp7c74.fsf@catnip.gol.com><000001c9d5ff$c53ebe10$0200a8c0@us.oracle.com> <87fxf5768e.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1242501745 29848 80.91.229.12 (16 May 2009 19:22:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 May 2009 19:22:25 +0000 (UTC) To: "'Miles Bader'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 16 21:22:18 2009 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 1M5PSZ-0006TY-Gt for ged-emacs-devel@m.gmane.org; Sat, 16 May 2009 21:22:17 +0200 Original-Received: from localhost ([127.0.0.1]:53110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5PSY-00013n-V2 for ged-emacs-devel@m.gmane.org; Sat, 16 May 2009 15:22:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M5PSU-00012M-CH for emacs-devel@gnu.org; Sat, 16 May 2009 15:22:10 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M5PSQ-00010w-ML for emacs-devel@gnu.org; Sat, 16 May 2009 15:22:10 -0400 Original-Received: from [199.232.76.173] (port=53235 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5PSQ-00010n-Ik for emacs-devel@gnu.org; Sat, 16 May 2009 15:22:06 -0400 Original-Received: from rcsinet12.oracle.com ([148.87.113.124]:52919 helo=rgminet12.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M5PSN-0003BJ-2x; Sat, 16 May 2009 15:22:03 -0400 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4GJLrmO009418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 May 2009 19:21:54 GMT Original-Received: from abhmt008.oracle.com (abhmt008.oracle.com [141.146.116.17]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4GJM11s025933; Sat, 16 May 2009 19:22:01 GMT Original-Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 16 May 2009 12:21:58 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87fxf5768e.fsf@catnip.gol.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnWB9yLx7qpVq/7SdWk1F2wpG4n4wARpXNw X-Source-IP: abhmt008.oracle.com [141.146.116.17] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A01020A.4A0F1256.0267:SCFSTAT5015188,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:110931 Archived-At: > >> For better or worse, Emacs traditionally distinguishes "the > >> minibuffer" from "the echo area", and resize-mini-windows > >> applies to both. So a name which captures this subtlety is > >> arguably better than one which lies a bit for the sake of > >> convenient document searching. > > > > And the name `resize-mini-windows' captures this subtlety > > just how? Is it because it cleverly doesn't mention _either_ > > the minibuffer or the echo area? That's supposed to help somehow? > > Sure. If no existing term captures a concept, then it seems a > reasonable argument that it's better to make a new term than use an > incorrect one. But no such new term was ever introduced (defined). If I simply refer in passing to the throndolt, have I helped you understand what a throndolt is? Same thing for `mini-window'. Just using the term does not introduce it; it does not "capture the concept". Of course, with enough use of the term, one might be able to figure it out, even without an explicit definition. But that is not the case here. The doc string talks only about resizing `mini-windows', without ever giving a clue what a `mini-window' is. Might as well talk about resizing `thronbolts'. > Of course, it's not always to come up with a good term, but > I'm not sure what other term would be better. The terms you > suggested are pithy, but seem inaccurate. You seem to be confusing two different things, under the slippery rubrique of "come up with a good term": 1. Introducing a new term altogether, which really requires defining it, giving some explanation of what `mini-window' refers to. 2. Combining existing defined terms into a phrase term: `minibuffer-echo-area-resize' is a "new term", but it's meaning is guessable from its known components `minibuffer' and `echo-area'. As Deniz pointed out, he would never have guessed that `resize-mini-windows' had _anything to do_ with the minibuffer. Besides that, how is `minibuffer-echo-area-resize' inaccurate? > Maybe it's better to just declare that "minibuffer-window" always > includes the echo-area, but it's not clear to me whether this > would run into other conflicts or not (e.g. uses of that term > that really only intend to refer to the minibuffer's window). I don't want to get involved in that discussion, at least not at this point. I'd simply advise to be careful what you bite off, to be sure you really want to chew and digest it all. There are many, many references to the minibuffer, its features, and how to use them. And many of those simply do not apply to the echo area. And, to a lesser extent, vice versa, there are references to the echo area that don't apply to the minibuffer. Even if the two concepts have a window (or screen area or whatever) in common, that doesn't mean they are not distinct concepts. Until now, it has been relatively simple to understand the model we present to the user: the minibuffer reads some user input; the echo area displays some output. That will become quite a bit more complicated if you conflate the two, or even just the windows. You will probably need to introduce two modes for this unified thingy: input mode (with completion or other `read' properties) and output mode. IOW, you might decide to conflate the windows, but most uses of those windows will need to remain distinct. The minibuffer and the echo area as we now understand them will come back, in one guise or another. Most importantly, if you really want to change the doc and UI terminology and presentation, then we should _start_ by deciding just what the user needs to understand about this (conceptual model), and _then_ decide on a terminology that fits that. We should not start by changing the language here and there, without knowing what model/concepts we are trying to introduce with that language change. > Perhaps the documentation could use improvement of course. > > Indeed, that seems like the most reasonable solution to this issue > (certainly in the short term): Make sure these variables are > mentioned in every place where they should be; in the end (while > apropos is very convenient, it's not a replacement for the real > documentation). If you are reading the doc about the minibuffer or the echo area, and these options are mentioned there, then you will understand them. No problem. That's already the case today. That's not the point. (We can perhaps add index entries to help you find such doc passages easier (e.g. when looking for `echo area' - `minibuffer' is already well indexed for resizing).) But if you are looking for such an option outside the manual, you should be able to find it easily using `C-h v' (with completion) or `apropos'. That's where aliases could help. `apropos', in particular, is perhaps the best tool we have for finding symbols based on parts of their names. (Well, second best, after Icicles ;-).) Even `apropos-documentation' won't help here, because the doc string refers only to the unexplained term `mini-windows', never mentioning `minibuffer' or `echo area'. IOW, neither the option name nor its doc string provides useful information about what the option is for.