RE: Rename `mini-' options

[Drew Adams]

> 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).