This page is part of the description of OneOnOneEmacs.
So, I prevented (via
‘default-frame-alist’) any frames from having a minibuffer, except a separate, special frame that is dedicated to the minibuffer. This frame, named
‘1on1-minibuffer-frame’ has these properties:
(minibuffer . only)’.
This means that you have only one place to look for the minibuffer. And it is long, giving you lots of room for informative messages, editing previously executed commands, icompletion choices, and so on.
See Library: Lisp:oneonone.el
Even with a display-wide standalone minibuffer, you will sometimes have input that covers more than two lines, which is the default height of the standalone frame (which you can control using option
‘1on1-minibuffer-frame-height’). To accomodate dynamic changes in input size, the standalone minibuffer frame is automatically resized after each user event (e.g typing a character) to fit its current content, provided user option
‘1on1-fit-minibuffer-frame-flag’ is non-
‘1on1-fit-minibuffer-frame-max-height-percent’ define the maximum possible height for this behavior. In addition, if you bind command
‘1on1-fit-minibuffer-frame’ to a key (I use
‘C-o’), then you can use that key repeatedly to increase the height by one line, even beyond the maximum. To take advantage of this feature, you must also have library fit-frame.el – see Shrink-Wrapping Frames.
I took advantage of the fact that frame
‘1on1-minibuffer-frame’ is dedicated to the minibuffer, by dynamically changing its background color slightly to indicate the status of the current user interaction (the colors are user variables):
This meant setting
‘isearch-mode-end-hook’ to take care of the isearch color changes. It also meant redefining these functions:
‘abort-recursive-edit’-- Reset the background to inactive.
‘y-or-n-p’– Temporarily change background to active, until user input.
Some minibuffer commands let you enter a recursive minibuffer. When the minibuffer is active – that is, when it is expecting input from you, it can be at different depths of recursion. In Emacs, there is no indication of this depth, or even of the fact that you are in a recursive minibuffer. (A recursive edit is indicated by bracketing (
[...]) in the mode line, but a recursive minibuffer is not indicated in any way.) To help you perceive the change to a new minibuffer recursion depth, the background hue (color) of the minibuffer frame is changed slightly with each depth change.
Here are screenshots showing this color change, together with a recursion-depth indicator (
3),…) at the left of the minibuffer. (The
+ sign followed by the colored rectangle are Icicles completion indicators – see Icicles - Nutshell View.)
Each of these background changes can improve orientation. Taken together, I find that they help quite a lot. Perhaps the most disorienting thing about Emacs is its various input modes, and the fact that there is generally little feedback about them.
‘minibuffer-depth’is. It now looks that will be added for Emacs 22, probably in the minibuffer itself. – DrewAdams
By “also”, I suppose you mean “as an alternative”, for OneOnOneEmacs, to changing the background color, since the change in frame background is already a good indication. There are two things to keep in mind about that alternative: 1) Face
‘minibuffer-prompt’ is not defined in Emacs versions prior to 22. 2) Changing existing faces is something that is better left to users, in their customizations, since they have different backgrounds, tastes etc.
If, on the other hand, you are advising users that they can customize face
‘minibuffer-prompt’, to make it better indicate an active minibuffer, then, yes, that is a good suggestion for people who don’t use OneOnOneEmacs. – DrewAdams