[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Rename `mini-' options

From: Drew Adams
Subject: RE: Rename `mini-' options
Date: Sat, 16 May 2009 12:21:55 -0700

> >> For better or worse, Emacs traditionally distinguishes "the
> >> minibuffer" from "the echo area", and resize-mini-windows 
> >> applies to both.  So a name which captures this subtlety is
> >> arguably better than one which lies a bit for the sake of
> >> convenient document searching.
> >
> > And the name `resize-mini-windows' captures this subtlety 
> > just how? Is it because it cleverly doesn't mention _either_
> > the minibuffer or the echo area?  That's supposed to help somehow?
> Sure.  If no existing term captures a concept, then it seems a
> reasonable argument that it's better to make a new term than use an
> incorrect one.

But no such new term was ever introduced (defined). If I simply refer in passing
to the throndolt, have I helped you understand what a throndolt is?

Same thing for `mini-window'. Just using the term does not introduce it; it does
not "capture the concept". Of course, with enough use of the term, one might be
able to figure it out, even without an explicit definition.

But that is not the case here. The doc string talks only about resizing
`mini-windows', without ever giving a clue what a `mini-window' is. Might as
well talk about resizing `thronbolts'.

> Of course, it's not always to come up with a good term, but 
> I'm not sure what other term would be better.  The terms you
> suggested are pithy, but seem inaccurate.

You seem to be confusing two different things, under the slippery rubrique of
"come up with a good term":

1. Introducing a new term altogether, which really requires defining it, giving
some explanation of what `mini-window' refers to.

2. Combining existing defined terms into a phrase term:
`minibuffer-echo-area-resize' is a "new term", but it's meaning is guessable
from its known components `minibuffer' and `echo-area'.

As Deniz pointed out, he would never have guessed that `resize-mini-windows' had
_anything to do_ with the minibuffer.

Besides that, how is `minibuffer-echo-area-resize' inaccurate?

> Maybe it's better to just declare that "minibuffer-window" always
> includes the echo-area, but it's not clear to me whether this 
> would run into other conflicts or not (e.g. uses of that term
> that really only intend to refer to the minibuffer's window).

I don't want to get involved in that discussion, at least not at this point. I'd
simply advise to be careful what you bite off, to be sure you really want to
chew and digest it all. There are many, many references to the minibuffer, its
features, and how to use them. And many of those simply do not apply to the echo
area. And, to a lesser extent, vice versa, there are references to the echo area
that don't apply to the minibuffer.

Even if the two concepts have a window (or screen area or whatever) in common,
that doesn't mean they are not distinct concepts.

Until now, it has been relatively simple to understand the model we present to
the user: the minibuffer reads some user input; the echo area displays some
output. That will become quite a bit more complicated if you conflate the two,
or even just the windows.

You will probably need to introduce two modes for this unified thingy: input
mode (with completion or other `read' properties) and output mode. IOW, you
might decide to conflate the windows, but most uses of those windows will need
to remain distinct. The minibuffer and the echo area as we now understand them
will come back, in one guise or another.

Most importantly, if you really want to change the doc and UI terminology and
presentation, then we should _start_ by deciding just what the user needs to
understand about this (conceptual model), and _then_ decide on a terminology
that fits that. We should not start by changing the language here and there,
without knowing what model/concepts we are trying to introduce with that
language change.

> Perhaps the documentation could use improvement of course.
> Indeed, that seems like the most reasonable solution to this issue
> (certainly in the short term):  Make sure these variables are 
> mentioned in every place where they should be; in the end (while
> apropos is very convenient, it's not a replacement for the real 
> documentation).

If you are reading the doc about the minibuffer or the echo area, and these
options are mentioned there, then you will understand them. No problem. That's
already the case today. That's not the point.

(We can perhaps add index entries to help you find such doc passages easier
(e.g. when looking for `echo area' - `minibuffer' is already well indexed for

But if you are looking for such an option outside the manual, you should be able
to find it easily using `C-h v' (with completion) or `apropos'. That's where
aliases could help. `apropos', in particular, is perhaps the best tool we have
for finding symbols based on parts of their names. (Well, second best, after
Icicles ;-).)

Even `apropos-documentation' won't help here, because the doc string refers only
to the unexplained term `mini-windows', never mentioning `minibuffer' or `echo
area'. IOW, neither the option name nor its doc string provides useful
information about what the option is for.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]