Point position in minibuffer-message

Point position in minibuffer-message

[Herbert Euler]

In the new Lisp level implementation of minibuffer-message,
temporarily displayed messages are displayed with overlay.  This
introduces a slight change on point position.  Previously, point is
put before temporarily displayed messages, whereas it is put after the
messages now.  Since the temporarily displayed messages are not part
of user input, I think it is better to put point before them, i.e. to
keep the behavior as before.

Just a suggestion.

Regards,
Guanpeng Xu
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx

RE: Point position in minibuffer-message

[Herbert Euler]

I forgot to say that I'm OK with the current behavior.
I just think it might be a surprise.

Regards,
Guanpeng Xu
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

Re: Point position in minibuffer-message

[Stefan Monnier]

> In the new Lisp level implementation of minibuffer-message,
> temporarily displayed messages are displayed with overlay.  This
> introduces a slight change on point position.  Previously, point is
> put before temporarily displayed messages, whereas it is put after the
> messages now.  Since the temporarily displayed messages are not part
> of user input, I think it is better to put point before them, i.e. to
> keep the behavior as before.

That's a good point.  I think the bug is in the C code that places the
cursor (since the overlay is all setup with advancing markers).
But maybe fixing the cursor code is difficult.

The use of an overlay with after-string was chosen so as to avoid other
minor problems, but this one might be more important,


        Stefan

Re: Point position in minibuffer-message

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> That's a good point.  I think the bug is in the C code that places the
> cursor (since the overlay is all setup with advancing markers).  But
> maybe fixing the cursor code is difficult.
>
> The use of an overlay with after-string was chosen so as to avoid
> other minor problems, but this one might be more important,

You can use the `cursor' property

--- minibuffer.el	13 Apr 2008 01:47:42 -0000	1.8
+++ minibuffer.el	13 Apr 2008 22:02:14 -0000
@@ -133,9 +133,11 @@
 If ARGS are provided, then pass MESSAGE through `format'."
   ;; Clear out any old echo-area message to make way for our new thing.
   (message nil)
-  (unless (and (null args) (string-match "\\[.+\\]" message))
+  (if (and (null args) (string-match "\\[.+\\]" message))
+      (setq message (copy-sequence message))
     (setq message (concat " [" message "]")))
   (when args (setq message (apply 'format message args)))
+  (add-text-properties 0 1 '(cursor t) message)
   (let ((ol (make-overlay (point-max) (point-max) nil t t)))
     (unwind-protect
         (progn

-- 
Johan Bockgård

Re: Point position in minibuffer-message

[Stefan Monnier]

>> That's a good point.  I think the bug is in the C code that places the
>> cursor (since the overlay is all setup with advancing markers).  But
>> maybe fixing the cursor code is difficult.
>> 
>> The use of an overlay with after-string was chosen so as to avoid
>> other minor problems, but this one might be more important,

> You can use the `cursor' property

Indeed, thanks.


        Stefan