wrapper fn for message and minibuffer-message?

wrapper fn for message and minibuffer-message?

[Drew Adams]

Ignore if already discussed or idea seems useless.

I have some commands that users can use either at top level or when in the
minibuffer. (In the latter case, they are bound to keys.)  I use the
following wrapper function, and I wonder if such a function might not be
useful generally, for defining Emacs commands that are likely to be (also)
bound in a minibuffer map.

Some toggle commands are examples of use cases - toggles that can take
effect while still inputting in the minibuffer.

(defun msg-maybe-in-minibuffer (string &rest args)
  "Display STRING with `message' or `minibuffer-message', as appropriate."
  (if (active-minibuffer-window)
      (minibuffer-message (format "  [%s]" string))
    (message string)))

No, this does not provide the generality of `message', which accepts a
format string and possibly other args to be formatted.  It might
nevertheless be useful.

Re: wrapper fn for message and minibuffer-message?

[Stefan Monnier]

> (defun msg-maybe-in-minibuffer (string &rest args)
>   "Display STRING with `message' or `minibuffer-message', as appropriate."
>   (if (active-minibuffer-window)
>       (minibuffer-message (format "  [%s]" string))
>     (message string)))

I agree 100% with the intention.  Typical such messages are the completion
messages, for completion functions that can be used both in the minibuffer
and in normal buffers.  E.g. the pcomplete functions.

Of course I'd define it more like

(defun msg-maybe-in-minibuffer (format &rest args)
  "Display STRING with `message' or `minibuffer-message', as appropriate."
  (if (minibufferp)
      (minibuffer-message (apply 'format (concat "  [" format "]") args))
    (apply 'message format args)))

I'd even argue that this function should be called "minibuffer-message",
since currently minibuffer-message is only used when (minibufferp) is
non-nil.


        Stefan

RE: wrapper fn for message and minibuffer-message?

[Drew Adams]

    > (defun msg-maybe-in-minibuffer (string &rest args)
    >   "Display STRING with `message' or `minibuffer-message', as
    appropriate."
    >   (if (active-minibuffer-window)
    >       (minibuffer-message (format "  [%s]" string))
    >     (message string)))

    I agree 100% with the intention.  Typical such messages are the
    completion messages, for completion functions that can be used
    both in the minibuffer and in normal buffers.

Yes, that's what I had in mind.

    Of course I'd define it more like

    (defun msg-maybe-in-minibuffer (format &rest args)
      "Display STRING with `message' or `minibuffer-message', as
appropriate."
      (if (minibufferp)
          (minibuffer-message (apply 'format (concat "  [" format "]")
args))
        (apply 'message format args)))

Yes. I use (active-minibuffer-window) because I want the code to work on
Emacs 20 also (where there is no `minibufferp').

Suggestion: Name the argument FORMAT-STRING, not FORMAT, for less confusion
with the function. (And use that name in the doc string, instead of STRING.)

(defun display-message (format-string &rest args)
  "Display FORMAT-STRING as a message.
If called with the minibuffer active, this is done using `message'.
Otherwise, it is done using `minibuffer-message'."
  (if (minibufferp)
      (minibuffer-message
        (apply 'format (concat "  [" format-string "]") args))
    (apply 'message format-string args)))


    I'd even argue that this function should be called "minibuffer-message",
    since currently minibuffer-message is only used when (minibufferp) is
    non-nil.

I'm confused here. If used outside of the minibuffer, it is not a
"minibuffer-message" at all, is it? Wouldn't the name `minibuffer-message'
be misleading, in that case?

The best name for the function would really be "message", with today's
`message' being called something like `log-message' (since it logs to
*Messages*).

Otherwise, if it's a no-no to co-opt the standard `message' name, a name
like "display-message" might be OK for this.

WDOT?

Re: wrapper fn for message and minibuffer-message?

[Richard M. Stallman]

    I'd even argue that this function should be called "minibuffer-message",
    since currently minibuffer-message is only used when (minibufferp) is
    non-nil.

I agree that is a natural generalization.  But I agree that this name
is not very clear for the current behavior, and even less clear for
the suggested behavior.

I can't think of a better name for this function, but I do have
an idea for a cleaner interface for the feature.  Have a variable
minibuffer-message-at-end which, if t, causes `message' to
display messages this way.

It could use the same mechanism as now; or, maybe it would
be cleaner to change the lower levels of redisplay to display
the message at the end of the minibuffer when it is selected.

RE: wrapper fn for message and minibuffer-message?

[Drew Adams]

        I'd even argue that this function should be called
        "minibuffer-message",
        since currently minibuffer-message is only used when
        (minibufferp) is non-nil.

    I agree that is a natural generalization.  But I agree that this name
    is not very clear for the current behavior, and even less clear for
    the suggested behavior.

I guess you didn't like the name "display-message" either (or co-opting the
name "message" for the wrapper function).

I think the name "minibuffer-message" is clear for its _current_ behavior -
what's unclear about it?

    I can't think of a better name for this function, but I do have
    an idea for a cleaner interface for the feature.  Have a variable
    minibuffer-message-at-end which, if t, causes `message' to
    display messages this way.

Not sure I understand. The important differences between `message' and
`minibuffer-message' today are these:

 - `message' exits the minibuffer (and recursive edit);
   `minibuffer-message' does not

 - `message' logs the message to *Messages*;
   `minibuffer-message' does not

 - `minibuffer-message' wraps the message in "  [...]";
   `message' does not

How would your suggestion relate to the first two differences?

In particular, a programmer must be able to control whether or not the
function exits the minibuffer. Today, that is done by using one or the
other: `message' or `minibuffer-message'.

How would the variable be set? Only explicitly, or would it also be set
implicitly, according to `minibufferp'? If the latter, how would a program
override that implicit behavior?

    It could use the same mechanism as now; or, maybe it would
    be cleaner to change the lower levels of redisplay to display
    the message at the end of the minibuffer when it is selected.

Sorry, I don't understand you, here. Could you elaborate a bit?

Re: wrapper fn for message and minibuffer-message?

[Richard M. Stallman]

    Not sure I understand. The important differences between `message' and
    `minibuffer-message' today are these:

     - `message' exits the minibuffer (and recursive edit);
       `minibuffer-message' does not

No it doesn't.

     - `message' logs the message to *Messages*;
       `minibuffer-message' does not

That is probably a bug.

     - `minibuffer-message' wraps the message in "  [...]";
       `message' does not

That's just a matter of how to make it stand out at the end of
the minibuffer.

RE: wrapper fn for message and minibuffer-message?

[Drew Adams]

        differences between `message' and `minibuffer-message':
         - `message' exits the minibuffer (and recursive edit);

    No it doesn't.

My bad.

         - `minibuffer-message' wraps the message in "  [...]";
           `message' does not

    That's just a matter of how to make it stand out at the end of
    the minibuffer.

Yes, of course.

I should also have mentioned this difference:

 - `message' temporarily erases the minibuffer before
   displaying the message; `minibuffer-message appends
   the message to the minibuffer contents, so both are
   visible together

I guess that's part of what you're referring to with your variable
`minibuffer-message-at-end': if non-nil, the message would be appended,
without first erasing the minibuffer.

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

If no, then what is now a simple call to `minibuffer-message' would require
something like (let ((minibuffer-message-at-end t)) (message ...)). If yes,
then a simple call to `message' could require (let
((minibuffer-message-at-end nil)) (message ...)). IIUC, I don't see the
advantage of the variable. But I'm probably missing something.

        It could use the same mechanism as now; or, maybe it would
        be cleaner to change the lower levels of redisplay to display
        the message at the end of the minibuffer when it is selected.

    Sorry, I don't understand you, here. Could you elaborate a bit?

 {}?

Do you mean that low-level redisplay would, in effect, use
`minibuffer-message' when the minibuffer is active and `message' otherwise?
If so, that's the behavior of the function I suggested.

However, if that is the behavior for `message', then my comment above
applies: you would need to do (let ((minibuffer-message-at-end nil))
(message ...)) to get the current effect of `message' (erase content first)
when the minibuffer is active. Sometimes you want to erase the minibuffer
first, even if the minibuffer is active. Most of the time you don't.

Why is your solution "cleaner" than just having `message' (erase first),
`minibuffer-message' (append without erasing), and a wrapper function that
DTRT most of the time (based on `minibufferp')?

Re: wrapper fn for message and minibuffer-message?

[Richard M. Stallman]

    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?
    If so, that's the behavior of the function I suggested.

No, it would implement the behavior of `minibuffer-message'
when `minibuffer-message-at-end' is non-nil.

RE: wrapper fn for message and minibuffer-message?

[Drew Adams]

        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.

Re: wrapper fn for message and minibuffer-message?

[Richard M. Stallman]

    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.

No.  The idea is that `message' would obey whatever the value
of `minibuffer-message-at-end' happens to be.

`minibuffer-message' could work by binding `minibuffer-message-at-end'
and calling `message'.

    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?

There is no need for one.  `minibuffer-message-at-end' would have no
effect when the minibuffer is not active.

RE: wrapper fn for message and minibuffer-message?

[Drew Adams]

        `minibuffer-message-at-end' would have no
        effect when the minibuffer is not active.

OK, I understand you now, I think. `message' does this:

if `minibufferp',
   then if `minibuffer-message-at-end'
        then don't erase minibuffer, but append message there
        else temporarily replace minibuffer contents with message
   else temporarily replace any minibuffer contents with message

`minibuffer-message' will just call `message' with non-nil
`minibuffer-message-at-end'. (However, to keep the current behavior in all
cases, it should not call `message' if the minibuffer is not active, but
should instead do nothing.)

Re: wrapper fn for message and minibuffer-message?

[Juri Linkov]

> OK, I understand you now, I think. `message' does this:
>
> if `minibufferp',
>    then if `minibuffer-message-at-end'
>         then don't erase minibuffer, but append message there
>         else temporarily replace minibuffer contents with message
>    else temporarily replace any minibuffer contents with message
>
> `minibuffer-message' will just call `message' with non-nil
> `minibuffer-message-at-end'. (However, to keep the current behavior in all
> cases, it should not call `message' if the minibuffer is not active, but
> should instead do nothing.)

I wonder if this can be used to display the isearch prompt while
searching the minibuffer contents?  Currently the isearch prompt
completely overwrites the minibuffer contents.  I imagine using
`minibuffer-message-at-end' to append the isearch prompt to the
minibuffer contents.  For example, with the minibuffer:

Eval: (setq foo 'bar)

typing `C-s foo' will display:

Eval: (setq foo 'bar) [I-search backward: foo]

and `foo' will be highlighted in `isearch' face, as usual.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: wrapper fn for message and minibuffer-message?

[Drew Adams]

    > OK, I understand you now, I think. `message' does this:
    >
    > if `minibufferp',
    >    then if `minibuffer-message-at-end'
    >         then don't erase minibuffer, but append message there
    >         else temporarily replace minibuffer contents with message
    >    else temporarily replace any minibuffer contents with message
    >
    > `minibuffer-message' will just call `message' with non-nil
    > `minibuffer-message-at-end'. (However, to keep the current
    > behavior in all cases, it should not call `message' if the
    > minibuffer is not active, but should instead do nothing.)

    I wonder if this can be used to display the isearch prompt while
    searching the minibuffer contents?  Currently the isearch prompt
    completely overwrites the minibuffer contents.  I imagine using
    `minibuffer-message-at-end' to append the isearch prompt to the
    minibuffer contents.  For example, with the minibuffer:

    Eval: (setq foo 'bar)
    typing `C-s foo' will display:
    Eval: (setq foo 'bar) [I-search backward: foo]
    and `foo' will be highlighted in `isearch' face, as usual.

Not bad (but don't you mean C-r for backward search)? I like it.

Anyway, this seems orthogonal to the discussion of merging message and
minibuffer-message. Couldn't this be done today, just by using
minibuffer-message instead of message?

Re: wrapper fn for message and minibuffer-message?

[Juri Linkov]

>     Eval: (setq foo 'bar)
>     typing `C-s foo' will display:
>     Eval: (setq foo 'bar) [I-search backward: foo]
>     and `foo' will be highlighted in `isearch' face, as usual.
>
> Not bad (but don't you mean C-r for backward search)?

Yes, C-r.

> Anyway, this seems orthogonal to the discussion of merging message and
> minibuffer-message. Couldn't this be done today, just by using
> minibuffer-message instead of message?

It seems neither minibuffer-message nor message will help here.
When I tried to use minibuffer-message, its delay after typing C-r
and before point moves to the next occurrence is too long.  Sorry.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: wrapper fn for message and minibuffer-message?

[Richard M. Stallman]

    Eval: (setq foo 'bar)

    typing `C-s foo' will display:

    Eval: (setq foo 'bar) [I-search backward: foo]

    and `foo' will be highlighted in `isearch' face, as usual.

I suggest that those who find this interesting try it out.

Searching in the minibuffer (was: wrapper fn for message and minibuffer-message?)

[Juri Linkov]

>     Eval: (setq foo 'bar)
>
>     typing `C-s foo' will display:
>
>     Eval: (setq foo 'bar) [I-search backward: foo]
>
>     and `foo' will be highlighted in `isearch' face, as usual.
>
> I suggest that those who find this interesting try it out.

This doesn't work satisfactorily: temporarily displaying the search
prompt at the end of the minibuffer causes too long delay after typing
C-s and before point moves to the next occurrence of the search string.

Instead of that, I propose a different solution:

1. not to display the search prompt while searching in the minibuffer
at all, because the search string is highlighted in the minibuffer anyway.
Thus the search prompt will not obscure the minibuffer text, and users
will be provided with visual feedback about the place the search reached.

2. to display the search prompt for 2 sec only when it contains
error messages.

Index: lisp/isearch.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.275
diff -c -r1.275 isearch.el
*** lisp/isearch.el	29 Sep 2005 22:55:53 -0000	1.275
--- lisp/isearch.el	17 Oct 2005 08:03:03 -0000
***************
*** 1926,1935 ****
                isearch-message)
  	    (isearch-message-suffix c-q-hack ellipsis)
  	    )))
!     (if c-q-hack
  	m
        (let ((message-log-max nil))
! 	(message "%s" m)))))
  
  (defun isearch-message-prefix (&optional c-q-hack ellipsis nonincremental)
    ;; If about to search, and previous search regexp was invalid,
--- 1934,1950 ----
                isearch-message)
  	    (isearch-message-suffix c-q-hack ellipsis)
  	    )))
!     (if (or c-q-hack
! 	    (and (minibufferp) isearch-success (not isearch-error)
! 		 (> (length isearch-string) 0)))
  	m
        (let ((message-log-max nil))
! 	(message "%s" m)
! 	(when (and (minibufferp) (not isearch-error))
! 	  (sit-for (or isearch-original-minibuffer-message-timeout
! 		       minibuffer-message-timeout
! 		       2))
! 	  (message ""))))))
  
  (defun isearch-message-prefix (&optional c-q-hack ellipsis nonincremental)
    ;; If about to search, and previous search regexp was invalid,

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Searching in the minibuffer (was: wrapper fn for message and minibuffer-message?)

[Richard M. Stallman]

    This doesn't work satisfactorily: temporarily displaying the search
    prompt at the end of the minibuffer causes too long delay after typing
    C-s and before point moves to the next occurrence of the search string.

Could you be more specific?  How long is the delay, and what causes it?

    1. not to display the search prompt while searching in the minibuffer
    at all, because the search string is highlighted in the minibuffer anyway.
    Thus the search prompt will not obscure the minibuffer text, and users
    will be provided with visual feedback about the place the search reached.

That's what it does now.  If people like that best, that's fine with me.

    2. to display the search prompt for 2 sec only when it contains
    error messages.

It would be useful for people to try this, too.

Re: Searching in the minibuffer

[Juri Linkov]

>     This doesn't work satisfactorily: temporarily displaying the search
>     prompt at the end of the minibuffer causes too long delay after typing
>     C-s and before point moves to the next occurrence of the search string.
>
> Could you be more specific?  How long is the delay, and what causes it?

The delay is 2 sec, and it is caused by sit-for in minibuffer-message.

>     1. not to display the search prompt while searching in the minibuffer
>     at all, because the search string is highlighted in the minibuffer anyway.
>     Thus the search prompt will not obscure the minibuffer text, and users
>     will be provided with visual feedback about the place the search reached.
>
> That's what it does now.  If people like that best, that's fine with me.

Currently the search prompt permanently obscures the minibuffer content.
My patch doesn't display the search prompt at all for successful search state.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Searching in the minibuffer

[Richard M. Stallman]

    >     This doesn't work satisfactorily: temporarily displaying the search
    >     prompt at the end of the minibuffer causes too long delay after typing
    >     C-s and before point moves to the next occurrence of the search string.
    >
    > Could you be more specific?  How long is the delay, and what causes it?

    The delay is 2 sec, and it is caused by sit-for in minibuffer-message.

sit-for is supposed exit whenever you type another character.
So in what sense does it cause a "delay"?

    My patch doesn't display the search prompt at all for successful search state.

That is a good option to add, I guess.

Re: Searching in the minibuffer

[Juri Linkov]

>     The delay is 2 sec, and it is caused by sit-for in minibuffer-message.
>
> sit-for is supposed exit whenever you type another character.
> So in what sense does it cause a "delay"?

In normal isearch operation (i.e. not in the minibuffer), typing C-s
immediately moves point to the next occurrence of the search string
and highlights it.

Having a delay in the minibuffer between typing C-s and seeing the search
string highlighted, or requiring to type another key to exit the delay,
would be a nuisance.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Searching in the minibuffer

[Richard M. Stallman]

    In normal isearch operation (i.e. not in the minibuffer), typing C-s
    immediately moves point to the next occurrence of the search string
    and highlights it.

    Having a delay in the minibuffer between typing C-s and seeing the search
    string highlighted, or requiring to type another key to exit the delay,
    would be a nuisance.

I agree.  If we display the search prompt at the end, clearly that
should be done after highlighting the string that was
found, so that it imposes no delay on seeing the highlighting.

Re: Searching in the minibuffer

[Juri Linkov]

>     Having a delay in the minibuffer between typing C-s and seeing
>     the search string highlighted, or requiring to type another key
>     to exit the delay, would be a nuisance.
>
> I agree.  If we display the search prompt at the end, clearly that
> should be done after highlighting the string that was
> found, so that it imposes no delay on seeing the highlighting.

Displaying the search prompt at the end of the minibuffer could be
placed in `isearch-update' after highlighting the search string.
But there is another problem - with lazy-highlighting.  `minibuffer-message'
doesn't allow lazy-highlighting timers to start.  This causes other
occurrences of the search string to be highlighted only after 2 sec delay,
and not 0.25 sec initial delay as specified by the default value of
`lazy-highlight-initial-delay'.

However, `isearch-update' can be changed to start the first
lazy-highlighting loop in the minibuffer immediately without timers.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Searching in the minibuffer

[Richard M. Stallman]

      `minibuffer-message'
    doesn't allow lazy-highlighting timers to start.

Clearly that could be fixed.  The real question is whether it is
useful to display the isearch prompt at the end in that way.  If that
is useful, changing the code to avoid these minor problems will not be
hard.  Don't think in terms of using the existing `minibuffer-message'
function's code.

RE: Searching in the minibuffer

[Drew Adams]

    The real question is whether it is
    useful to display the isearch prompt at the end in that way.  If that
    is useful, changing the code to avoid these minor problems will not be
    hard.  Don't think in terms of using the existing `minibuffer-message'
    function's code.

My 2c:

Having isearch highlighting in the minibuffer will help.

Having an isearch message there too (e.g. appended to mb content) would also
help some, but is not as important. A "Failing..." message is a
nice-to-have - you don't have to look extra hard for highlighting that isn't
there.