I still have the same question: Would the variable also be
set to non-nil implicitly, whenever `minibufferp'?
(That was the behavior I originally suggested: use
`minibuffer-message' when the minibuffer is active.)
That is certainly not what I have in mind. These are both useful
operations in the minibuffer. The individual command would bind
`minibuffer-message-at-end' to non-nil when it wants the message to
appear at the end of the minibuffer.
Do you mean that low-level redisplay would, in effect, use
`minibuffer-message' when the minibuffer is active and
`message' otherwise?
No, it would implement the behavior of `minibuffer-message'
when `minibuffer-message-at-end' is non-nil.
OK. If I understand you correctly, you would keep functions `message' and
`minibuffer-message' as they are now. You would not eliminate either
function. The former's default behavior would use nil for
`minibuffer-message-at-end'; the latter would use non-nil.
The only change you would make would be to introduce the variable, so that a
user could bind `minibuffer-message-at-end' to flip the behavior of either
function from its default behavior. When `minibuffer-message-at-end' is nil,
the minibuffer content is temporarily replaced by the message (as is done
today by `message'); when it is non-nil, the content remains, and the
message is appended to it.
You are not interested in any wrapper function that uses the minibuffer
state (active or inactive) to determine the `minibuffer-message-at-end'
behavior.
Is that correct?
I ask because it's still not clear to me what you propose. You said that the
variable allowed a "cleaner interface for the feature", and I thought the
feature in question was the one I originally suggested: using the minibuffer
state to determine the `minibuffer-message-at-end' behavior.
_______________________________________________
Emacs-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-devel
