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:20:06 -0700 Message-ID: <002501c9d65b$54210d30$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> <003101c9d5dd$b4a5e730$0200a8c0@us.oracle.com> <83fxf5qs6x.fsf@gnu.org> 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 1242501647 29631 80.91.229.12 (16 May 2009 19:20:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 May 2009 19:20:47 +0000 (UTC) Cc: lekktu@gmail.com, deniz.a.m.dogan@gmail.com, emacs-devel@gnu.org To: "'Eli Zaretskii'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 16 21:20:40 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 1M5PR1-0005sp-PW for ged-emacs-devel@m.gmane.org; Sat, 16 May 2009 21:20:40 +0200 Original-Received: from localhost ([127.0.0.1]:52618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5PR0-0000Uc-P9 for ged-emacs-devel@m.gmane.org; Sat, 16 May 2009 15:20:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M5PQt-0000Ts-Ug for emacs-devel@gnu.org; Sat, 16 May 2009 15:20:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M5PQp-0000Rq-An for emacs-devel@gnu.org; Sat, 16 May 2009 15:20:31 -0400 Original-Received: from [199.232.76.173] (port=53193 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5PQp-0000Rj-3p for emacs-devel@gnu.org; Sat, 16 May 2009 15:20:27 -0400 Original-Received: from rcsinet12.oracle.com ([148.87.113.124]:51687 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 1M5PQl-0002zH-VH; Sat, 16 May 2009 15:20:24 -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 n4GJK7YZ007515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 May 2009 19:20:08 GMT Original-Received: from abhmt007.oracle.com (abhmt007.oracle.com [141.146.116.16]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4GJKFis024496; Sat, 16 May 2009 19:20:15 GMT Original-Received: from dradamslap1 (/98.210.250.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 16 May 2009 12:20:12 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83fxf5qs6x.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnWDdVnwdqdlMPkTHOfmZ+9olP/4wAQM8YA X-Source-IP: abhmt007.oracle.com [141.146.116.16] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4A0F11ED.000F: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:110930 Archived-At: > Let me say up front that I don't object to have variables whose names > include ``minibuffer'' rather than ``mini'', if that makes someone > happy. We could add aliases to the currently-named variables, which > should be harmless even at this late stage of the pretest. We could > also add index entries in the manuals, which is even less harmful, > just to ease searching for them. Good. That was all I proposed. Let's do that. The rest of this discussion is accessory - a related but separate topic. > You are wrong. Maybe the documentation is misleading or inaccurate, The doc plus the UI (names the user sees) are all that I spoke about. I am not wrong about those. You are apparently saying in fact that the doc and UI are wrong, that they do not faithfully reflect the internals of the product. You go on to show that the doc and UI do not correspond to what actually happens in the C internals, in the sense that there is a C code entity with "echo" and "area" in its name, and that is associated with the minibuffer window. That may be, but it is irrelevant here, unless we decide that the user's mental model should correspond more faithfully with the implementation (in fact, with that part of the implementation that s?he does not see directly when interacting with Emacs: C code). If we decide that, then the doc and UI names need to be changed, to teach users a model that better reflects what the implementation actually does. The question is what model to present to the users: what do they need, to understand all of the _behavior that they can see_. User-observable behavior is the key to defining a helpful conceptual model for the user. The implementation is an aid in doing that, but it is not the guide. The guide is the user's point of view and what s?he can actually do and see when interacting with the program. If the echo area window that you refer to in the C code is something that the user cannot observe and interact with - e.g. s?he cannot treat it as an Emacs window, then perhaps it should not be part of the user's mental model. I'm no expert on whether that is the case - you decide. The idea, as always, is to come up with a conceptual model for the user that reflects (preferably all) _user observable_ behavior. User models reflect implementations, but they generally abstract from what the user cannot see or touch. I would suggest limiting the meaning of "observable", for Emacs, to what users experience interactively and by using Lisp. > but the echo area is indeed just a special use of the minibuffer > window. This fact is clearly visible from the C code that is the > infrastructure for displaying text in the echo area. The following > snippet is from xdisp.c:echo_area_display: >... > In plain English, this does the following: > . finds the currently selected frame > . then gets the minibuffer window used by that frame > . and finally, uses that window to display the echo area contents >... > So, not only is the echo area using the minibuffer window on the > selected frame, there's also a Lisp object, called echo_area_window, > which specifies that window as long as it is in use. Which means > that, if the need arises, we could have a Lisp-level binding for that > object, and then Lisp programs could use it in many ways like any > other window. > > It is true that this window is special in many ways, which could > explain why the documentation is so vague about it. But please don't > claim with such certainty that it's not a window, because that's > simply false. So the documentation is misleading, and has been so since Day 1, in particular in the very places where it introduces (defines) these concepts - I cited the relevant sections, in case you want to correct them. However, that said, the question remains of how this should be presented to users conceptually. You had recourse to the C code, admitting that the echo area window is not currently Lisp-accessible. That is, you cannot use it as a window from Lisp (which confirms what I said). As long as this internal, special window is not available to (Lisp) users, should we even introduce it at all, to become part of the user's conceptual model? That's a choice to be made. Currently, the doc does not present it that way at all. The "echo area" in the doc is a different animal altogether from the `echo_area_window' C variable, even though the names are similar. If we choose not to introduce the concept of an echo area _window_, that is, if we continue the current (doc) approach, then there is still the question whether to say that the echo area borrows the minibuffer window or, as is said currently, that the minibuffer window is displayed in the "screen area" that either (a) is known as the "echo area" (Emacs manual) or (b) has the same location as the echo area (Elisp manual).