all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Miles Bader <miles@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Rename `mini-' options
Date: Sat, 16 May 2009 18:18:39 +0900	[thread overview]
Message-ID: <87skj5e780.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <87r5yp7c74.fsf@catnip.gol.com>

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.




  parent reply	other threads:[~2009-05-16  9:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-16  1:47 Rename `mini-' options Davis Herring
2009-05-16  2:11 ` Drew Adams
2009-05-16  2:22   ` Juanma Barranquero
2009-05-16  2:32     ` Drew Adams
2009-05-16  3:09       ` Juanma Barranquero
2009-05-16  4:20         ` Drew Adams
2009-05-16 10:04           ` Eli Zaretskii
2009-05-16 19:20             ` Drew Adams
2009-05-16 19:47           ` Juanma Barranquero
2009-05-16  6:43         ` Stephen J. Turnbull
2009-05-16  7:13           ` Miles Bader
2009-05-16  8:24             ` Drew Adams
2009-05-16  9:21               ` Miles Bader
2009-05-16 19:21                 ` Drew Adams
2009-05-17  1:59                   ` Miles Bader
2009-05-16  9:18             ` Stephen J. Turnbull [this message]
2009-05-17  4:10             ` Stefan Monnier
     [not found] <AcnVoAMCDVZ2cc3/RpaKtCkusD8ZRg==>
2009-05-15 20:59 ` Drew Adams
2009-05-16  0:12   ` Deniz Dogan
2009-05-16  0:21     ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87skj5e780.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --cc=emacs-devel@gnu.org \
    --cc=miles@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.