From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Rename `mini-' options Date: Sat, 16 May 2009 13:04:54 +0300 Message-ID: <83fxf5qs6x.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1242468314 31733 80.91.229.12 (16 May 2009 10:05:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 May 2009 10:05:14 +0000 (UTC) Cc: lekktu@gmail.com, deniz.a.m.dogan@gmail.com, emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 16 12:05:07 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 1M5GlO-0001ZE-Ei for ged-emacs-devel@m.gmane.org; Sat, 16 May 2009 12:05:07 +0200 Original-Received: from localhost ([127.0.0.1]:57423 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5GlN-0006ih-RA for ged-emacs-devel@m.gmane.org; Sat, 16 May 2009 06:05:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M5GlH-0006ib-Un for emacs-devel@gnu.org; Sat, 16 May 2009 06:04:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M5GlG-0006iJ-8u for emacs-devel@gnu.org; Sat, 16 May 2009 06:04:58 -0400 Original-Received: from [199.232.76.173] (port=38626 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5GlG-0006iG-40 for emacs-devel@gnu.org; Sat, 16 May 2009 06:04:58 -0400 Original-Received: from mtaout4.012.net.il ([84.95.2.10]:34429 helo=mtaout3.012.net.il) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M5GlF-0006iO-Ef for emacs-devel@gnu.org; Sat, 16 May 2009 06:04:57 -0400 Original-Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KJQ00L00ENNI300@i_mtaout3.012.net.il> for emacs-devel@gnu.org; Sat, 16 May 2009 13:04:55 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.73.80]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KJQ00JQ6EO6FGD0@i_mtaout3.012.net.il>; Sat, 16 May 2009 13:04:55 +0300 (IDT) In-reply-to: <003101c9d5dd$b4a5e730$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 9.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:110922 Archived-At: > From: "Drew Adams" > Date: Fri, 15 May 2009 21:20:54 -0700 > Cc: emacs-devel@gnu.org, 'Deniz Dogan' 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. But that issue aside, I would like to everybody be on the right page regarding whether echo are is or isn't 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. You are wrong. Maybe the documentation is misleading or inaccurate, 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: struct frame *sf = SELECTED_FRAME (); mini_window = FRAME_MINIBUF_WINDOW (sf); w = XWINDOW (mini_window); [...] echo_area_window = mini_window; window_height_changed_p = display_echo_area (w); w->must_be_updated_p = 1; 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 (For people who are not fluent in reading Emacs C sources: mini_window and w are two ways of specifying the same window: the former is a Lisp object that refers to the minibuffer window, the latter is a pointer to a C data structure which specifies that same window. The macro XWINDOW takes a Lisp object for a window and returns a C pointer for that window.) 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.