From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juanma Barranquero'" <lekktu@gmail.com>
Cc: emacs-devel@gnu.org, 'Deniz Dogan' <deniz.a.m.dogan@gmail.com>
Subject: RE: Rename `mini-' options
Date: Fri, 15 May 2009 21:20:54 -0700 [thread overview]
Message-ID: <003101c9d5dd$b4a5e730$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <f7ccd24b0905152009m655042e9w9f782316c6126599@mail.gmail.com>
> > 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.
next prev parent reply other threads:[~2009-05-16 4:20 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 [this message]
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
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='003101c9d5dd$b4a5e730$0200a8c0@us.oracle.com' \
--to=drew.adams@oracle.com \
--cc=deniz.a.m.dogan@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=lekktu@gmail.com \
/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.