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: Fri, 15 May 2009 21:20:54 -0700 Message-ID: <003101c9d5dd$b4a5e730$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> 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 1242447668 25139 80.91.229.12 (16 May 2009 04:21:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 May 2009 04:21:08 +0000 (UTC) Cc: emacs-devel@gnu.org, 'Deniz Dogan' To: "'Juanma Barranquero'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 16 06:21:01 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 1M5BOO-0002MR-Ko for ged-emacs-devel@m.gmane.org; Sat, 16 May 2009 06:21:01 +0200 Original-Received: from localhost ([127.0.0.1]:43584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5BOO-0005v7-2m for ged-emacs-devel@m.gmane.org; Sat, 16 May 2009 00:21:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M5BOJ-0005us-Ee for emacs-devel@gnu.org; Sat, 16 May 2009 00:20:55 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M5BOE-0005uN-PJ for emacs-devel@gnu.org; Sat, 16 May 2009 00:20:54 -0400 Original-Received: from [199.232.76.173] (port=38119 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5BOE-0005uI-LE for emacs-devel@gnu.org; Sat, 16 May 2009 00:20:50 -0400 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:30127) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M5BOE-0002ey-41 for emacs-devel@gnu.org; Sat, 16 May 2009 00:20:50 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4G4KSZR015397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 May 2009 04:20:29 GMT Original-Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4G4LBup012835; Sat, 16 May 2009 04:21:11 GMT Original-Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 May 2009 21:20:37 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcnV09cU6iJPQ+0MRNCr2P+Sc9zlXQAAmphw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010204.4A0E3F16.023C: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:110913 Archived-At: > > I did not say anything about the frame's minibuffer window. > > And yes, the minibuffer window is a window. > > You said: > > > The minibuffer and the echo area share the same screen real > > estate. But it's not a window - "window" means something > > specific in Emacs. Yes, I did. The echo area is not an Emacs window. See if `select-window' and such can handle it. See if the doc ever refers to it as a window. No and no. > What is the difference between the frame's minibuffer window, and the > screen real state used by the minibuffer? (Unless you're trying to > imply that the "screen real state" is not a window, because a window > is an Emacs object, which would be handwaving IMO). Not handwaving at all. That is how Emacs has always talked about the echo area - as an area of the screen where the minibuffer is displayed for input and output messages are echoed. You will not find it referred to in the doc as a "window". You will instead see that the doc says that the "line at the very bottom of the frame is the `echo area'". And that "The echo area is also used to display the "minibuffer", a special window..." And that "At the very bottom of the frame is a special `echo area', where short informative messages are displayed and where you enter information when Emacs asks for it." And the Elisp manual: "The `echo-area' is used for displaying error messages... It is not the same as the minibuffer, despite the fact that the minibuffer appears (when active) in the same place on the screen as the echo area." The Elisp manual says that the echo area and the minibuffer appear in the same place - without naming that place. The Emacs manual calls that place the "echo area" - an area at the bottom of the screen. There is thus some minor terminology mismatch between the two manuals, but neither refers to that area as a "window", AFAIK - they both call it an "area" of the screen, avoiding the term "window". That area is sometimes used to _display_ a window, the minibuffer window. But certainly not the echo-area window. > > 1. I said that the _echo area_ is not an Emacs window. > > Do you dispute that point? > > No. I dispute that you said 1. Here's exactly what I said: "But it's not a window - `window' means something specific in Emacs." And "it" refers here to the echo area. I clearly said that the echo area is not an Emacs window. On what basis do you dispute that? > Because Davis said > > The mini-window is the window that holds the minibuffer, but also > > the echo area > and your answer was: > > > Nice try ;-). But you're simply making that up. Yes, making up the term "mini-window". You will not find it anywhere in the doc. That doesn't imply that I never said that the echo area is not a window. > As for the other points, the manual says: > > The variable `max-mini-window-height', which specifies the maximum > height for resizing minibuffer windows, also applies to the echo area > (which is really a special use of the minibuffer window. *Note > Minibuffer Misc::.). I disagree with that characterization. Perhaps it was written by the same person who coined those unhelpful option names - I don't know. Based on what I quoted above from the Emacs manual, you might say that the minibuffer is a special use of the echo area, but not the other way around. (The Elisp manual would say that they are both special uses of a special, unnamed area at the bottom of the screen.) See the Emacs manual, where it actually introduces and _defines_ the term, which I quoted above. What you quoted is just the description of the very option whose terminology is in question! Did the same person write that doc and name the option? > so, on one hand, it is not very difficult to find what is > max-mini-widow-height used for; What is more difficult than it should be is _finding_ the options that control resizing of the minibuffer and its height. Completion, `apropos', and other common search tools won't help you, as I pointed out. It doesn't matter whether you're looking for an option that controls the minibuffer height or the echo area height - looking for either `minibuffer' or `echo-area' in the option name will not find it. > and, on the other hand, changing it to max-minibuffer-window-height > would obscure the fact that the echo area is also affected. The doc string can explain exactly what is affected, as precisely as you like. The point of having a useful name is to help users find the critter in the first place. I personally would have no objection to either aliasing a name that contains `echo-area' or even having a long name that contains both `minibuffer' and `echo-area'. (There are several variables whose names contain `echo-area' - see the Elisp manual, node Echo Area Customization.) Neither of those approaches would be my preference, however - I don't think that's necessary, but I recognize that someone could make the same argument for trying to find options that affect the echo area height, so I concede that putting `echo-area' in the name could help. I don't concede that `mini-' helps someone find an option that affects the echo area. I made a simple proposal to rename a couple of options. You apparently just want to argue in circles about what I said or didn't say.