Re: Potential problem of minibuffer-message

[Kenichi Handa <handa@m17n.org>]

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