From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Rename `mini-' options Date: Sat, 16 May 2009 18:18:39 +0900 Message-ID: <87skj5e780.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1242465179 24691 80.91.229.12 (16 May 2009 09:12:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 May 2009 09:12:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 16 11:12:52 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 1M5Fwo-0002Dm-1Q for ged-emacs-devel@m.gmane.org; Sat, 16 May 2009 11:12:50 +0200 Original-Received: from localhost ([127.0.0.1]:33586 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5Fwn-0008R3-96 for ged-emacs-devel@m.gmane.org; Sat, 16 May 2009 05:12:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M5Fwf-0008PH-9o for emacs-devel@gnu.org; Sat, 16 May 2009 05:12:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M5Fwa-0008Kf-4S for emacs-devel@gnu.org; Sat, 16 May 2009 05:12:40 -0400 Original-Received: from [199.232.76.173] (port=59509 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5FwZ-0008KV-TB for emacs-devel@gnu.org; Sat, 16 May 2009 05:12:35 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:37730) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M5FwX-0006co-1L; Sat, 16 May 2009 05:12:33 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 04FDD820F; Sat, 16 May 2009 18:12:30 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C8E151A4583; Sat, 16 May 2009 18:18:39 +0900 (JST) In-Reply-To: <87r5yp7c74.fsf@catnip.gol.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta28) "fuki" 83e35df20028+ XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:110920 Archived-At: Miles Bader writes: > The variable in question _is_ existing practice -- it was introduced > almost a decade ago, in Emacs 21. OK, then fix the docs to explain the difference between "mini-window" and "minibuffer window", and use the concept appropriately. But this is another case where I'm glad that XEmacs hasn't kept up to GNU Emacs "existing practice". I think it's perfectly reasonable to document the echo area as "borrowing" the minibuffer window, rather than creating a new concept of "mini-windows" (which don't actually exist, anyway). > That (long obsolete) mode does something _different_ than > resize-mini-windows: it only applies to the minibuffer. Actually, it doesn't. At least in the XEmacs implementation, the echo area really does borrow the minibuffer window, so to the extent that the minibuffer expansion persists (which it normally does, as repetitions of similar long prompts etc. are common), so does the echo area. There were also some fragile hacks that allowed the echo area to expand as well. > Thus even if referring to "minibuffer-window" makes sense for that > mode, that doesn't mean it makes sense for Emacs' builtin behavior. Maybe not. I think that says more about your sense of "sense" than it does about Drew's proposal, though. :-) > [I suppose you could argue against the "echo area"/"minibuffer" split, > and say we should just refer to them both as "the minibuffer" > (or whatever), but that's a different argument (and certainly not > something that should happen right now, as it's a big change).] My point, and Drew's, is that as far as the *window* goes, that *is* existing practice. Even the documentation of the *-mini-* functions refers to the "minibuffer window", not to the "mini-window", and so do you long-time developers.