RE: wrapper fn for message and minibuffer-message?

["Drew Adams" <drew.adams@oracle.com>]

        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.