Potential problem of minibuffer-message

Potential problem of minibuffer-message

[Kenichi Handa]

I'd like to install the attached change.

Currently, minibuffer-message calls temp_echo_area_glyphs
with the arg SDATA (string), and temp_echo_area_glyphs
inserts it by insert_string function.  But insert_string
should not be used for the contents of Lisp string.  My fix
changes the arg of temp_echo_area_glyphs to Lisp string, and
use insert_from_string to insert it.

I also want to add the optional arg TIMEOUT to
minibuffer-message and temp_echo_area_glyphs.  It is to
specify how long to display the text instead of the defualt
two seconds.

I need TIMEOUT because I'm going to change quail to use just
`message' (normal case) or `minibuffer-message' (the case of
inputting in a minibuffer) to display the guidance string.
In the latter case, the two seconds is too short.

By the way, minibuffer-message is not described in Elisp
info nor in NEWS.

---
Ken'ichi HANDA
handa@m17n.org

*** minibuf.c.~1.254.~	Sat Jan 25 09:10:34 2003
--- minibuf.c	Thu Apr 10 10:35:29 2003
***************
*** 1719,1725 ****
    if (NILP (completion))
      {
        bitch_at_user ();
!       temp_echo_area_glyphs (" [No match]");
        UNGCPRO;
        return 0;
      }
--- 1719,1725 ----
    if (NILP (completion))
      {
        bitch_at_user ();
!       temp_echo_area_glyphs (build_string (" [No match]"), Qnil);
        UNGCPRO;
        return 0;
      }
***************
*** 1783,1789 ****
        else if (!NILP (Vcompletion_auto_help))
  	Fminibuffer_completion_help ();
        else
! 	temp_echo_area_glyphs (" [Next char not unique]");
        return 6;
      }
    else if (completedp)
--- 1783,1789 ----
        else if (!NILP (Vcompletion_auto_help))
  	Fminibuffer_completion_help ();
        else
! 	temp_echo_area_glyphs (build_string (" [Next char not unique]"), Qnil);
        return 6;
      }
    else if (completedp)
***************
*** 1882,1894 ****
      case 1:
        if (PT != ZV)
  	Fgoto_char (make_number (ZV));
!       temp_echo_area_glyphs (" [Sole completion]");
        break;
  
      case 3:
        if (PT != ZV)
  	Fgoto_char (make_number (ZV));
!       temp_echo_area_glyphs (" [Complete, but not unique]");
        break;
      }
  
--- 1882,1895 ----
      case 1:
        if (PT != ZV)
  	Fgoto_char (make_number (ZV));
!       temp_echo_area_glyphs (build_string (" [Sole completion]"), Qnil);
        break;
  
      case 3:
        if (PT != ZV)
  	Fgoto_char (make_number (ZV));
!       temp_echo_area_glyphs (build_string (" [Complete, but not unique]"),
! 			     Qnil);
        break;
      }
  
***************
*** 1949,1955 ****
      case 4:
        if (!NILP (Vminibuffer_completion_confirm))
  	{
! 	  temp_echo_area_glyphs (" [Confirm]");
  	  return Qnil;
  	}
        else
--- 1950,1956 ----
      case 4:
        if (!NILP (Vminibuffer_completion_confirm))
  	{
! 	  temp_echo_area_glyphs (build_string (" [Confirm]"), Qnil);
  	  return Qnil;
  	}
        else
***************
*** 1986,1992 ****
    if (NILP (completion))
      {
        bitch_at_user ();
!       temp_echo_area_glyphs (" [No match]");
        return Qnil;
      }
    if (EQ (completion, Qt))
--- 1987,1993 ----
    if (NILP (completion))
      {
        bitch_at_user ();
!       temp_echo_area_glyphs (build_string (" [No match]"), Qnil);
        return Qnil;
      }
    if (EQ (completion, Qt))
***************
*** 2344,2350 ****
    if (NILP (completions))
      {
        bitch_at_user ();
!       temp_echo_area_glyphs (" [No completions]");
      }
    else
      internal_with_output_to_temp_buffer ("*Completions*",
--- 2345,2351 ----
    if (NILP (completions))
      {
        bitch_at_user ();
!       temp_echo_area_glyphs (build_string (" [No completions]"), Qnil);
      }
    else
      internal_with_output_to_temp_buffer ("*Completions*",
***************
*** 2388,2402 ****
  }
  
  \f
! /* Temporarily display the string M at the end of the current
!    minibuffer contents.  This is used to display things like
!    "[No Match]" when the user requests a completion for a prefix
!    that has no possible completions, and other quick, unobtrusive
!    messages.  */
  
  void
! temp_echo_area_glyphs (m)
!      const char *m;
  {
    int osize = ZV;
    int osize_byte = ZV_BYTE;
--- 2389,2403 ----
  }
  
  \f
! /* Temporarily display STRING at the end of the current minibuffer
!    contents for TIMEOUT seconds.  This is used to display things like
!    "[No Match]" when the user requests a completion for a prefix that
!    has no possible completions, and other quick, unobtrusive
!    messages.  If TIMEOUT is not number, it defaults to 2.  */
  
  void
! temp_echo_area_glyphs (string, timeout)
!      Lisp_Object string, timeout;
  {
    int osize = ZV;
    int osize_byte = ZV_BYTE;
***************
*** 2409,2418 ****
    message (0);
  
    SET_PT_BOTH (osize, osize_byte);
!   insert_string (m);
    SET_PT_BOTH (opoint, opoint_byte);
    Vinhibit_quit = Qt;
!   Fsit_for (make_number (2), Qnil, Qnil);
    del_range_both (osize, osize_byte, ZV, ZV_BYTE, 1);
    SET_PT_BOTH (opoint, opoint_byte);
    if (!NILP (Vquit_flag))
--- 2410,2421 ----
    message (0);
  
    SET_PT_BOTH (osize, osize_byte);
!   insert_from_string (string, 0, 0, SCHARS (string), SBYTES (string), 0);
    SET_PT_BOTH (opoint, opoint_byte);
    Vinhibit_quit = Qt;
!   if (! NUMBERP (timeout))
!     timeout = make_number (2);
!   Fsit_for (timeout, Qnil, Qnil);
    del_range_both (osize, osize_byte, ZV, ZV_BYTE, 1);
    SET_PT_BOTH (opoint, opoint_byte);
    if (!NILP (Vquit_flag))
***************
*** 2424,2438 ****
  }
  
  DEFUN ("minibuffer-message", Fminibuffer_message, Sminibuffer_message,
!        1, 1, 0,
         doc: /* Temporarily display STRING at the end of the minibuffer.
! The text is displayed for two seconds,
! or until the next input event arrives, whichever comes first.  */)
!      (string)
!      Lisp_Object string;
  {
    CHECK_STRING (string);
!   temp_echo_area_glyphs (SDATA (string));
    return Qnil;
  }
  \f
--- 2427,2445 ----
  }
  
  DEFUN ("minibuffer-message", Fminibuffer_message, Sminibuffer_message,
!        1, 2, 0,
         doc: /* Temporarily display STRING at the end of the minibuffer.
! The text is displayed for two seconds by default,
! or until the next input event arrives, whichever comes first.
! The optional second arg TIMEOUT, if non-nil, specifies how long to
! display the text instead of two seconds.  */)
!      (string, timeout)
!      Lisp_Object string, timeout;
  {
    CHECK_STRING (string);
!   if (! NILP (timeout))
!     CHECK_NUMBER (timeout);
!   temp_echo_area_glyphs (string, timeout);
    return Qnil;
  }
  \f

Re: Potential problem of minibuffer-message

[Stefan Monnier]

> I'd like to install the attached change.
> 
> Currently, minibuffer-message calls temp_echo_area_glyphs
> with the arg SDATA (string), and temp_echo_area_glyphs
> inserts it by insert_string function.  But insert_string
> should not be used for the contents of Lisp string.  My fix
> changes the arg of temp_echo_area_glyphs to Lisp string, and
> use insert_from_string to insert it.
> 
> I also want to add the optional arg TIMEOUT to
> minibuffer-message and temp_echo_area_glyphs.  It is to
> specify how long to display the text instead of the defualt
> two seconds.
> 
> I need TIMEOUT because I'm going to change quail to use just
> `message' (normal case) or `minibuffer-message' (the case of
> inputting in a minibuffer) to display the guidance string.
> In the latter case, the two seconds is too short.
> 
> By the way, minibuffer-message is not described in Elisp
> info nor in NEWS.

As part of my still-in-progress rewrite of completion in elisp,
I use the following (partly taken from complete.el where it is
called PC-temp-minibuffer-message or somesuch).

Note how it already works in both case: from the minibuffer or
from some other buffer.  And actually pcomplete needs to be patched
to use this function in place of `message' so as to be more usable
for minibuffer-completion.


	Stefan


(defun minibuffer-message (message &rest args)
  "Temporarily display STRING at the end of the minibuffer.
The text is displayed for `minibuffer-message-timeout' seconds,
or until the next input event arrives, whichever comes first."
  (cond ((not (minibuffer-p (current-buffer)))
	 (apply 'message message args)
	 (sit-for (or minibuffer-message-timeout 1000000))
	 (message nil))
	(t
	 (let ((point-max (point-max)))
	   (message nil)
	   (save-excursion
	     (goto-char point-max)
	     (insert (apply 'format (if (string-match "\\[.*\\]" message)
					message
				      (concat " [" message "]"))
			    args))
	     (let ((inhibit-quit t))
	       (sit-for (or minibuffer-message-timeout 1000000))
	       (delete-region point-max (point))
	       (when quit-flag
		 (setq quit-flag nil
		       unread-command-events '(7)))))))))

Re: Potential problem of minibuffer-message

[Kenichi Handa]

In article <200304101344.h3ADiMe3003713@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> As part of my still-in-progress rewrite of completion in elisp,
> I use the following (partly taken from complete.el where it is
> called PC-temp-minibuffer-message or somesuch).

Ah! Your version is surely superior.  But...

> Note how it already works in both case: from the minibuffer or
> from some other buffer.

This facility is surplus in my case (i.e. in quail) because
quail should show different guidance messages in a normal
case and in a minibuffer case anyway.

Richard Stallman <rms@gnu.org> writes:
> These changes seem good to me.

I've just installed this bug fix only.

2003-04-11  Kenichi Handa  <handa@m17n.org>

	* lisp.h (temp_echo_area_glyphs): Adjust prototype.

	* minibuf.c (temp_echo_area_glyphs): Change the arg to Lisp
	string.  Caller changed.

I'll leave it Stefan and Richard as to these matters.

o Should minibuffer-message has the same argument as message?

o Should it pay attention to the case of being called from
  non-minibuffer?  Should it automatically re-format the
  message to " [...]"?

o Should it use minibuffer-message-timeout as timeout?

For the moment, for quail, I'll use my own version
quail-minibuffer-message which is the simplified version of
Stefan's one.

By the way, I'd like to raise these points too.

o Isn't it better to take care of modified and read-only
  flags of the minibuffer?

o If a rear-advancing overlay is in the minibufer and it
  has face (or any hooks) property, simply inserting a
  message yields an unpleasant result.  It seems that we
  should have a new function insert-after-markers (analogous
  to insert-before-markers).

---
Ken'ichi HANDA
handa@m17n.org

Re: Potential problem of minibuffer-message

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> o If a rear-advancing overlay is in the minibufer and it
>   has face (or any hooks) property, simply inserting a
>   message yields an unpleasant result.  It seems that we
>   should have a new function insert-after-markers (analogous
>   to insert-before-markers).

How about using an overlay with an `after-string' property, located at
the end of the minibuffer, for the minibuffer-message message itself?
Then there's no modification/insertion at all...

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: Potential problem of minibuffer-message

[Kenichi Handa]

In article <buoptntwyg9.fsf@mcspd15.ucom.lsi.nec.co.jp>, Miles Bader <miles@lsi.nec.co.jp> writes:
> How about using an overlay with an `after-string' property, located at
> the end of the minibuffer, for the minibuffer-message message itself?
> Then there's no modification/insertion at all...

Unfortunately, the cursor is shown after that `after-string'
in that case.

---
Ken'ichi HANDA
handa@m17n.org

Re: Potential problem of minibuffer-message

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> > How about using an overlay with an `after-string' property, located at
> > the end of the minibuffer, for the minibuffer-message message itself?
> > Then there's no modification/insertion at all...
> 
> Unfortunately, the cursor is shown after that `after-string'
> in that case.

Oh yeah, that !@#*& problem -- I ran in the same thing when I was trying
to do my `error messages don't obscure the users input' patch a long time
ago.

That behavior really should simply be fixed, it's stupid
(but unfortunately, not entirely trivial to fix either).

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

overlay property `after-string'

[Kenichi Handa]

I changed Subject:

In article <buollyhwsws.fsf@mcspd15.ucom.lsi.nec.co.jp>, Miles Bader <miles@lsi.nec.co.jp> writes:
> Kenichi Handa <handa@m17n.org> writes:
>>  > How about using an overlay with an `after-string' property, located at
>>  > the end of the minibuffer, for the minibuffer-message message itself?
>>  > Then there's no modification/insertion at all...
>>  
>>  Unfortunately, the cursor is shown after that `after-string'
>>  in that case.

> Oh yeah, that !@#*& problem -- I ran in the same thing when I was trying
> to do my `error messages don't obscure the users input' patch a long time
> ago.

> That behavior really should simply be fixed, it's stupid
> (but unfortunately, not entirely trivial to fix either).

I'm not sure that the current behaviour is a bug.

(let (overlay)
  (insert "abc")
  (setq overlay (make-overlay (- (point) 3) (point)))
  (overlay-put overlay 'after-string "hello")
  (sit-for 2)
  (delete-overlay overlay))

In this case, it seems that the current behaviour is correct
(i.e. the cursor is shown after "hello").

---
Ken'ichi HANDA
handa@m17n.org

Re: overlay property `after-string'

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> I'm not sure that the current behaviour is a bug.
...
> In this case, it seems that the current behaviour is correct
> (i.e. the cursor is shown after "hello").

It's dependent on the insertion-type of the overlay; basically, the
cursor should be displayed relative to the overlay text wherever text
will be inserted relative to the overlay text.

For instance, try this modified version of your example:

   (let (overlay)
     (insert "abc")
     (setq overlay (make-overlay (- (point) 3) (point) nil nil t))
     (overlay-put overlay 'after-string "[hello]"))

Now type -- whoa, wierd!

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: overlay property `after-string'

[Kenichi Handa]

In article <buofzopwrs0.fsf@mcspd15.ucom.lsi.nec.co.jp>, Miles Bader <miles@lsi.nec.co.jp> writes:
> It's dependent on the insertion-type of the overlay; basically, the
> cursor should be displayed relative to the overlay text wherever text
> will be inserted relative to the overlay text.

> For instance, try this modified version of your example:

>    (let (overlay)
>      (insert "abc")
>      (setq overlay (make-overlay (- (point) 3) (point) nil nil t))
>      (overlay-put overlay 'after-string "[hello]"))

> Now type -- whoa, wierd!

I see your point.  You mean this:
    Showing the cursor at where the next typed character
    will be displayed.
Correct?

I agree that it is the best behaviour, but, yes, fixing
seems very difficult.

By the way, we will encouter this very tricky case, but it
seems ok to igore such a case.

(let (ov1 ov2)
  (insert "abcdef")
  (setq ov1 (make-overlay (- (point) 6) (- (point) 3) nil nil t))
  (overlay-put ov1 'after-string "[hello]")
  (setq ov2 (make-overlay (- (point) 3) (point)))
  (overlay-put ov2 'before-string "[world]")
  (forward-char -3)
  (unwind-protect
      (while t
	(insert (read-char))
	(message (format "%d-%d, %d-%d" 
			 (overlay-start ov1) (overlay-end ov1)
			 (overlay-start ov2) (overlay-end ov2))))
    (delete-overlay ov1)
    (delete-overlay ov2)))

---
Ken'ichi HANDA
handa@m17n.org

Re: Potential problem of minibuffer-message

[Richard Stallman]

    o Should minibuffer-message has the same argument as message?

Those two functions are not really similar; there is no need for this
incompatible change.

    o Should it pay attention to the case of being called from
      non-minibuffer?  Should it automatically re-format the
      message to " [...]"?

I see no importance in this, but I have no objection to it
if someone finds it useful and wants to do it.

    o Should it use minibuffer-message-timeout as timeout?

I think the optional arg is good enough.  But if you have a specific
use for adding minibuffer-message-timeout, please do.

    o Isn't it better to take care of modified and read-only
      flags of the minibuffer?

Would you please be more specific?

    o If a rear-advancing overlay is in the minibufer and it
      has face (or any hooks) property, simply inserting a
      message yields an unpleasant result.  It seems that we
      should have a new function insert-after-markers (analogous
      to insert-before-markers).

Either that, or minibuffer-message-timeout could find all overlays on
the first character of the message, and move their ends back where
they belong.

I would expect that the latter is a less complex change overall.

Re: Potential problem of minibuffer-message

[Richard Stallman]

These changes seem good to me.