messages override minibuffer input

messages override minibuffer input

[Roland Winkler]

I am always annoyed when emacs is waiting for input in the
minibuffer, and in the meanwhile an (idle-) timer function kicks in,
producing a message that overrides the content displayed in the
minibuffer. I was once told that timer functions should be designed
such that they do not produce any output. I do not know whether this
is always a good strategy. On the other hand, I do not know how many
(too many?) packages violate such a strategy. (Probably, it would
help if the elisp manual gave a recommendation concerning the usage
of noisy functions inside timer functions.)

However, I believe that interactive minibuffer input could compete or
cooperate in a more flexible / customizable way with noisy timer
functions. For example, I can think of a user option that allows one
to specify after how much idle time a noisy timer function may
override the content displayed in the minibuffer. (Nonetheless, such
messages could always go to the *Messages* buffer.) Or that option
could allow to specify a time minimum for minibuffer inactivity till
any timer function is allowed to kick in. Often, the problem occurs
for me while I am inactive for just a second or two. So it seems to
me that, anyway, there are not too many jobs emacs can get done
during that time.

Roland

Re: messages override minibuffer input

[Stefan Monnier]

> However, I believe that interactive minibuffer input could compete or
> cooperate in a more flexible / customizable way with noisy timer
> functions. For example, I can think of a user option that allows one

Another way to do it is to make such async-messages appear *after* the
current minibuffer's content (typically enclosed on backets, as is done for
completion messages).


        Stefan

Re: messages override minibuffer input

[Davis Herring]

> I am always annoyed when emacs is waiting for input in the
> minibuffer, and in the meanwhile an (idle-) timer function kicks in,
> producing a message that overrides the content displayed in the
> minibuffer. I was once told that timer functions should be designed
> such that they do not produce any output. I do not know whether this
> is always a good strategy. On the other hand, I do not know how many
> (too many?) packages violate such a strategy. (Probably, it would
> help if the elisp manual gave a recommendation concerning the usage
> of noisy functions inside timer functions.)

When I have written timers that produced output, it has been
"informational" output which is not critical to see; then I have merely
skipped printing unless the echo area either is empty or contains my
timer's previous output, and the minibuffer is not active.  Would this be
a good general function to provide?  (What follows is not tested; I don't
have known-working code to hand.)

(defvar optional-message nil
  "The last message shown with the function `optional-message'.")
(defun optional-message (fmt &rest args)
  "Display a message if there's nothing better being displayed."
  (or (active-minibuffer-window)
      (not (eq (current-message) optional-message))
      (message "%s" (setq optional-message (apply 'format fmt args)))))

I suppose some provision could be made for putting the message into
*Messages* even if it's not displayed, but I'm not sure what the best way
to do that is.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: messages override minibuffer input

[Richard Stallman]

    When I have written timers that produced output, it has been
    "informational" output which is not critical to see; then I have merely
    skipped printing unless the echo area either is empty or contains my
    timer's previous output, and the minibuffer is not active.  Would this be
    a good general function to provide?

Can you look for places in the sources where it would be right to use
`optional-message'?  If you find many, then the function would be a good
feature.

    I suppose some provision could be made for putting the message into
    *Messages* even if it's not displayed, but I'm not sure what the best way
    to do that is.

You can write Lisp code to do the same things now done at C level.  We
could also turn that C code into a subr, if that is useful.

Re: messages override minibuffer input

[Johannes Weiner]

[-- Attachment #1.1: Type: text/plain, Size: 707 bytes --]

Hi,

On Mon, Sep 10, 2007 at 02:41:26PM -0700, Davis Herring wrote:
> (defvar optional-message nil
>   "The last message shown with the function `optional-message'.")
> (defun optional-message (fmt &rest args)
>   "Display a message if there's nothing better being displayed."
>   (or (active-minibuffer-window)
>       (not (eq (current-message) optional-message))
>       (message "%s" (setq optional-message (apply 'format fmt args)))))

ELISP> (progn (setq foo "foo") (message foo) (eq (current-message) foo))
nil

This function calls `message' only when the minibuffer is active.  I am sorry,
I can not follow that logic.

How likely is it anyway that two EQUAL strings are messaged in a row?

	Hannes

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: messages override minibuffer input

[Johannes Weiner]

[-- Attachment #1.1: Type: text/plain, Size: 755 bytes --]

Hi,

On Wed, Sep 12, 2007 at 11:25:45AM +0200, Johannes Weiner wrote:
> > (defun optional-message (fmt &rest args)
> >   "Display a message if there's nothing better being displayed."
> >   (or (active-minibuffer-window)
> >       (not (eq (current-message) optional-message))
> >       (message "%s" (setq optional-message (apply 'format fmt args)))))
> 
> ELISP> (progn (setq foo "foo") (message foo) (eq (current-message) foo))
> nil
> 
> This function calls `message' only when the minibuffer is active.

Whoops, got it backwards.  The call to `message' happens only when the
minibuffer is inactive.  But anyway, the second argument to `or' still seems
useless to me, because `current-message' returns a new string object.

	Hannes

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: messages override minibuffer input

[Davis Herring]

> Whoops, got it backwards.  The call to `message' happens only when the
> minibuffer is inactive.  But anyway, the second argument to `or' still
> seems
> useless to me, because `current-message' returns a new string object.

It is; I thought one could use eq here, but it seems equal is required. 
Which is not as good: a stream of unimportant messages could then proceed
if the first of them happened to duplicate an important message.  I guess
we could stick an "unimportant" property on unimportant messages and then
compare them with `equal-including-properties'.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: messages override minibuffer input

[Davis Herring]

> How likely is it anyway that two EQUAL strings are messaged in a row?

Maybe you understand already, but the purpose of that test (the
implementation of which I discuss in another message) is to allow the
message to go through only if the last message displayed was also
unimportant (that is, displayed with `optional-message').

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: messages override minibuffer input

[Davis Herring]

> Can you look for places in the sources where it would be right to use
> `optional-message'?  If you find many, then the function would be a good
> feature.

Places where `optional-message' might be useful:
autorevert.el, in `auto-revert-handler'
desktop.el, in `desktop-idle-create-buffers'
help-at-pt.el: see approximate reimplementation in `help-at-pt-maybe-display'
speedbar.el, in `speedbar-timer-fn'
emacs-lisp/eldoc.el, in `eldoc-message', perhaps to replace
`eldoc-display-message-no-interference-p'
perhaps erc/erc-backend.el, in the PRIVMSG response handler
perhaps erc/erc-notify.el, in `erc-notify-timer'
gnus/mm-decode.el, in the process sentinels in `mm-display-external'
gnus/nntp.el, in `nntp-accept-process-output'
progmodes/cperl-mode.el, in `cperl-get-help'
progmodes/idlwave.el, in `idlwave-load-rinfo-next-step'
progmodes/vhdl-mode.el, in `vhdl-print-warnings'
textmodes/reftex-dcr.el: see approximate reimplementation in
`reftex-view-crossref-when-idle'
emacs-lock.el, in `emacs-lock-clear-sentinel'
find-dired.el, in `find-dired-sentinel'
man.el, in `Man-notify-when-ready'
pcvs.el, in `cvs-sentinel'
vc-arch.el, in the lambdas created in `vc-arch-trim-make-sentinel'
eshell/esh-proc.el, in `eshell-remove-process-entry'
progmodes/sql.el, in `sql-stop'
perhaps progmodes/xscheme.el, in `xscheme-process-sentinel'
url/url.el: see approximate reimplementation in `url-lazy-message'

I just checked lisp/; I do not think very much asynchronous messaging
occurs in src/.

> You can write Lisp code to do the same things now done at C level.  We
> could also turn that C code into a subr, if that is useful.

True, but how should client code request it?  I can't add an optional
argument to `optional-message' and have it work like `message' now, of
course.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: messages override minibuffer input

[Luc Teirlinck]

   help-at-pt.el: see approximate reimplementation in
   `help-at-pt-maybe-display'

Yes, but the difference with the way I read (quickly) your function is
fundamental: `help-at-pt-maybe-display' _does_ override a "Quit"
message and this is absolutely necessary for correct functioning.
So at least this function should be left as is.

Sincerely,

Luc.

Re: messages override minibuffer input

[Davis Herring]

> Yes, but the difference with the way I read (quickly) your function is
> fundamental: `help-at-pt-maybe-display' _does_ override a "Quit"
> message and this is absolutely necessary for correct functioning.
> So at least this function should be left as is.

I don't claim that my suggested implementation is final; perhaps a way to
override certain existing messages could be included.  (One could already
simply let-bind the variable `optional-message' to pretend that "Quit" was
the last one, but that would fail when the existing message was some other
optional message to be overwritten.  As a kludge, one could call
`optional-message' with and without the let-binding, but at that point the
existing implementation is probably better.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: messages override minibuffer input

[Richard Stallman]

You have found plenty of justification for adding `optional-message'.

    > You can write Lisp code to do the same things now done at C level.  We
    > could also turn that C code into a subr, if that is useful.

    True, but how should client code request it?  I can't add an optional
    argument to `optional-message' and have it work like `message' now, of
    course.

Is it right for clients to have to request it?
I think it should be controlled by a user option, that's all.

Re: messages override minibuffer input

[Roland Winkler]

On Sat Sep 8 2007 Richard Stallman wrote:
>     I am always annoyed when emacs is waiting for input in the
>     minibuffer, and in the meanwhile an (idle-) timer function kicks in,
>     producing a message that overrides the content displayed in the
>     minibuffer.
> 
> Which are the packages and messages that actually annoy you in this
> way?  Maybe those packages should be changed, or silenced.

I apologize the delayed reply. I had to do some more digging in the
code to understand more precisley what annoys me:

I have some timer functions that use autoloaded functions. A simple
test case is

(defun foo () (regexp-opt '("bar" "baz")))
(run-at-time 3 nil 'foo)

This will create a message "Loading regexp-opt...done" if regexp-opt
was not yet loaded. This message can override the content displayed
in the minibuffer.

If I understand the code correctly, the function do_autoload in
eval.c normally calls load with arg NOMESSAGE being nil. So load
issues a message. Would it make sense that load used something like
optional-message?

Roland

Re: messages override minibuffer input

[Richard Stallman]

    If I understand the code correctly, the function do_autoload in
    eval.c normally calls load with arg NOMESSAGE being nil. So load
    issues a message. Would it make sense that load used something like
    optional-message?

That change goes too far.  In the case you describe, do_autoload
should not display the message.  But in many other cases it should.

Perhaps do_autoload, when called from a timer, should not display the
message.  But it should put the message in *Messages*.

Ideally it should display the message, but restore the previous echo
area contents later.  The hard part of that is arranging for the
proper "later" time.

Re: messages override minibuffer input

[Roland Winkler]

On Sun Sep 16 2007 Richard Stallman wrote:
>     If I understand the code correctly, the function do_autoload in
>     eval.c normally calls load with arg NOMESSAGE being nil. So load
>     issues a message. Would it make sense that load used something like
>     optional-message?
> 
> That change goes too far.  In the case you describe, do_autoload
> should not display the message.  But in many other cases it should.

Would it be better to do what Stefan proposed in a previous post?

  Another way to do it is to make such async-messages appear *after*
  the current minibuffer's content (typically enclosed on backets,
  as is done for completion messages).

Roland

Re: messages override minibuffer input

[Richard Stallman]

    Would it be better to do what Stefan proposed in a previous post?

      Another way to do it is to make such async-messages appear *after*
      the current minibuffer's content (typically enclosed on backets,
      as is done for completion messages).

That method sounds good for some cases.  Maybe it is good for this
case.  The next step is to propose specific conditions in which this
method would be used.

Re: messages override minibuffer input

[Davis Herring]

>     If I understand the code correctly, the function do_autoload in
>     eval.c normally calls load with arg NOMESSAGE being nil. So load
>     issues a message. Would it make sense that load used something like
>     optional-message?
>
> That change goes too far.  In the case you describe, do_autoload
> should not display the message.  But in many other cases it should.

I think that `load' should display the first message "Loading foo..."
regardless, since Emacs looks hung during the load and so an explanation
is needed.  The "Loading foo...done" message should be displayed as an
optional message, except that if it is not displayed the contents of the
echo area (or minibuffer) from /before/ the load should be restored.

> Ideally it should display the message, but restore the previous echo
> area contents later.  The hard part of that is arranging for the
> proper "later" time.

Currently `message' has a temporary effect if invoked while the minibuffer
is active.  What is the mechanism for this?  I can't see how Fmessage
arranges it.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: messages override minibuffer input

[Stefan Monnier]

> That change goes too far.  In the case you describe, do_autoload
> should not display the message.  But in many other cases it should.

Good you mention it because I've been meaning to ask (for a long time
already) why it is that autoloading a package causes a "loading
<foo>" message.
You seem to say it has an important role to play, but I never found it
useful, and I always found it odd that autoloading displays such
messages while requiring a package doesn't.  What am I missing?


        Stefan

Re: messages override minibuffer input

[Roland Winkler]

On Mon Sep 17 2007 Richard Stallman wrote:
>       Another way to do it is to make such async-messages appear *after*
>       the current minibuffer's content (typically enclosed on backets,
>       as is done for completion messages).
> 
> That method sounds good for some cases.  Maybe it is good for this
> case.  The next step is to propose specific conditions in which this
> method would be used.

My knowledge is limited when it can happen that messages can
override minibuffer input. Initially, I thought only of messages
from asynchronous processes like timer functions. Then I realized
that messages can also show up that refer to my current minibuffer
input. For example, I want to do a regexp search for which I enter
in the minibuffer something like "[}". Then I get the message
"Mismatched parentheses" that overwrites my minibuffer input.
Indeed, such messages have always confused me as much as the
messages from asynchronous processes. I cannot think of any
situation right now where it appears justified to me to overwrite
the display of the minibuffer while I edit the content of the
minibuffer. Stefan's suggestion appears much more transparent / less
confusing to me.

Roland

Re: messages override minibuffer input

[Richard Stallman]

    My knowledge is limited when it can happen that messages can
    override minibuffer input. Initially, I thought only of messages
    from asynchronous processes like timer functions. Then I realized
    that messages can also show up that refer to my current minibuffer
    input.

In cases like this, the echo area message disappears after a
few seconds, or whenever you type another character.  So I think
those are not a problem.  Why do you consider that a problem?

What about the timer case?  Does the message disappear after
a few seconds, or whenever you type another character?

Re: messages override minibuffer input

[Roland Winkler]

On Sun Sep 23 2007 Richard Stallman wrote:
>     My knowledge is limited when it can happen that messages can
>     override minibuffer input. Initially, I thought only of messages
>     from asynchronous processes like timer functions. Then I realized
>     that messages can also show up that refer to my current minibuffer
>     input.
> 
> In cases like this, the echo area message disappears after a
> few seconds, or whenever you type another character.  So I think
> those are not a problem.  Why do you consider that a problem?

It is true that a message like "Mismatched parentheses" disappears
again after a few seconds.

Yet quite generally, it confuses me when I type something and
suddenly the text I have typed disappears. Even when the message
disappears again when I continue typing, a smooth work flow requires
that I know the last character I typed before the message appeared
so that I know where to continue typing while something else is
displayed.

However, minibuffer input is often more complicated (for example, a
regexp), i.e., I do need the visual feedback that I see what I have
typed and even a temporary message "Mismatched parentheses" annoys me.
(If I try to pay attention to the message overwriting the
minibuffer, I will definitely forget how to continue typing.)

> What about the timer case?  Does the message disappear after
> a few seconds, or whenever you type another character?

In the timer case the message does not disappear by itself after a
few seconds, i.e., it is always necessary to continue typing
blindly.

Roland

Re: messages override minibuffer input

[Richard Stallman]

    Yet quite generally, it confuses me when I type something and
    suddenly the text I have typed disappears. Even when the message
    disappears again when I continue typing, a smooth work flow requires
    that I know the last character I typed before the message appeared
    so that I know where to continue typing while something else is
    displayed.

If we put such messages at the end, that may cause the minibuffer
to grow by a line.  Would you find that disturbing?

If not, perhaps the thing to do is to put the message below the
current input, always growing the minibuffer.  Or put the message
above the minibuffer contents.  What would you think of that?

Re: messages override minibuffer input

[Richard Stallman]

    You seem to say it has an important role to play, but I never found it
    useful, and I always found it odd that autoloading displays such
    messages while requiring a package doesn't.  What am I missing?

I wasn't aware of that oddity, but now that you mention it,
I don't see a need for them to be different.
So we can turn off the messages for autoloading.

Would you like to do that?

Re: messages override minibuffer input

[Roland Winkler]

On Sun Sep 23 2007 Richard Stallman wrote:
>     Yet quite generally, it confuses me when I type something and
>     suddenly the text I have typed disappears. Even when the message
>     disappears again when I continue typing, a smooth work flow requires
>     that I know the last character I typed before the message appeared
>     so that I know where to continue typing while something else is
>     displayed.
> 
> If we put such messages at the end, that may cause the minibuffer
> to grow by a line.  Would you find that disturbing?
> 
> If not, perhaps the thing to do is to put the message below the
> current input, always growing the minibuffer.  Or put the message
> above the minibuffer contents.  What would you think of that?

It appears more natural to me to put the message at the end than
above the minibuffer contents. In a case like the message
"Mismatched parentheses" point will usually be at the end of the
minibuffer so that the relation between minibuffer input and the
issued message is most obvious. (Conversely, one might argue that a
message issued by a timer function is not related to the current
minibuffer input. So if such a message was put above the minibuffer
contents, that would make it more clear to the user that the message
is asynchronous, not related to current minibuffer input. But such a
"deluxe" solution might be difficult to implement. Also, it is in a
way more confusing because a temporary message will make minibuffer
input move by a line when the message disappears again.)

Whether the message should go at the end of the current line or in a
new line might depend on the window width. Generally, readability is
best if there are no linebreaks within a message. For a narrow
window it appears thus better to me if the message is displayed in a
new line. If the window width is large it might be more convenient
to append the message at the end of the current line.

Even if the minibuffer grows by a line (thus shifting point upwards
by one line), in my opinion this is by far less a nuisance because I
know immediately what I typed last before the message popped up and
where / how I want to continue typing.

Currently, if (due to whatever reason) the minibuffer grows by a line
while it is active, it will keep this maximum size till minibuffer
input has been completed. I believe it would make sense to implement
a similar policy for "minibuffer + (temporary) messages".

Roland

RE: messages override minibuffer input

[Drew Adams]

>     Yet quite generally, it confuses me when I type something and
>     suddenly the text I have typed disappears. Even when the message
>     disappears again when I continue typing, a smooth work flow requires
>     that I know the last character I typed before the message appeared
>     so that I know where to continue typing while something else is
>     displayed.
>
> If we put such messages at the end, that may cause the minibuffer
> to grow by a line.  Would you find that disturbing?
>
> If not, perhaps the thing to do is to put the message below the
> current input, always growing the minibuffer.  Or put the message
> above the minibuffer contents.  What would you think of that?

Please don't do that. In general, let's try to keep echo-area messages to
one line. If they happen to be so long that they wrap, so be it. So I'd
request that we append without a newline.

RE: messages override minibuffer input

[Roland Winkler]

On Sun Sep 23 2007 Drew Adams wrote:
> > If we put such messages at the end, that may cause the minibuffer
> > to grow by a line.  Would you find that disturbing?
> >
> > If not, perhaps the thing to do is to put the message below the
> > current input, always growing the minibuffer.  Or put the message
> > above the minibuffer contents.  What would you think of that?
> 
> Please don't do that. In general, let's try to keep echo-area messages to
> one line. If they happen to be so long that they wrap, so be it. So I'd
> request that we append without a newline.

Maybe I misunderstand something here. I thought that the question
was about messages placed at the end of a minibuffer line. So if the
minibuffer takes already 70 display columns and the message requires
another 70 columns I don't know how the message could fit into a
standard window with 80 display columns unless the message is
wrapped. In such a (standard?) case it would seem more natural to me
to put the message completely into a new line. (But I do agree that
this might be a matter of personal preference.) If, on the other
hand, the last line displayed in the minibuffer takes only 30
columns and the message is a short "Mismatched parentheses" then it
would be sufficient to display the message at the end of that line.

Roland

RE: messages override minibuffer input

[Drew Adams]

> > > If we put such messages at the end, that may cause the minibuffer
> > > to grow by a line.  Would you find that disturbing?
> > >
> > > If not, perhaps the thing to do is to put the message below the
> > > current input, always growing the minibuffer.  Or put the message
> > > above the minibuffer contents.  What would you think of that?
> >
> > Please don't do that. In general, let's try to keep echo-area
> > messages to one line. If they happen to be so long that they
> > wrap, so be it. So I'd request that we append without a newline.
>
> Maybe I misunderstand something here. I thought that the question
> was about messages placed at the end of a minibuffer line. So if the
> minibuffer takes already 70 display columns and the message requires
> another 70 columns I don't know how the message could fit into a
> standard window with 80 display columns unless the message is
> wrapped. In such a (standard?) case it would seem more natural to me
> to put the message completely into a new line.

It will wrap anyway if it is too long for the window size. That is, the
window width will automatically determine whether and where to visually add
a new line.

Different users have different width minibuffer windows. I, for instance,
use a standalone minibuffer frame that stretches all the way across my
display. On the display I'm using right now, it has room for 160 characters.
When I'm use other displays, it is narrower or wider; it always fills the
display width.

It is not a good idea to start inserting newlines in message text based on
assumptions of a standard (or any other) minibuffer width or height. Just
treat the echo area as a single long line, and let it wrap as needed.

That doesn't mean there could never be newlines in the echo area under any
circumstances. I'm just saying that there is no good reason to add them for
no good reason, and based on a window-size assumption.

RE: messages override minibuffer input

[Roland Winkler]

On Sun Sep 23 2007 Drew Adams wrote:
> It is not a good idea to start inserting newlines in message text based on
> assumptions of a standard (or any other) minibuffer width or height. Just
> treat the echo area as a single long line, and let it wrap as needed.
> 
> That doesn't mean there could never be newlines in the echo area under any
> circumstances. I'm just saying that there is no good reason to add them for
> no good reason, and based on a window-size assumption.

I do not know how difficult it might be to come up with a smart
solution for inserting linebreaks. In the context of this thread a
solution without or with linebreaks is equally acceptable for me.

Roland

Re: messages override minibuffer input

[Stefan Monnier]

>     You seem to say it has an important role to play, but I never found it
>     useful, and I always found it odd that autoloading displays such
>     messages while requiring a package doesn't.  What am I missing?

> I wasn't aware of that oddity, but now that you mention it,
> I don't see a need for them to be different.
> So we can turn off the messages for autoloading.

> Would you like to do that?

Done,


        Stefan

Re: messages override minibuffer input

[Robert J. Chassell]

Drew Adams said

    [a line in the minibuffer] will wrap anyway if it is too long for
    the window size.

Do you mean wrap with fill at the fill column (by convention 70
characters) or do you mean wrap without filling, which, on 80 column
wide frames, may break a word between the 80 and 81 columns so the
rest of the line can move down?

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: messages override minibuffer input

[Johannes Weiner]

[-- Attachment #1.1: Type: text/plain, Size: 1247 bytes --]

Hi,

On Sun, Sep 23, 2007 at 05:54:44PM -0400, Richard Stallman wrote:
> If we put such messages at the end, that may cause the minibuffer
> to grow by a line.  Would you find that disturbing?
> 
> If not, perhaps the thing to do is to put the message below the
> current input, always growing the minibuffer.  Or put the message
> above the minibuffer contents.  What would you think of that?

Growing is not smooth.  If you grow to the top, the above line distracts you
if you normally read text from top to bottom.  If you grow to the bottom, the
original minibuffer line where you currently type in moves one line up.  So I
would prefer to avoid growing the minibuffer whenever possible.  If the
content wraps, then growing to the bottom as it is right now, is okay.

A clean solution would be, to have messages concerning your current input
(Mismatched parenthesis, ...) appear at the end of the minibuffer in brackets.
Other messages from timers and such go to *Messages* and if you are finished
typing in the minibuffer, you will get a (message "New stuff in *Messages*")
for exapmle.

How does that sound, disregarding implementation details? :)

	Hannes

-- 
3BD8 AF56 11AF 205C 9DB6  B10F 76F1 0634 71A4 DCA0

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: messages override minibuffer input

[David Kastrup]

Johannes Weiner <hannes@saeurebad.de> writes:

> Hi,
>
> On Sun, Sep 23, 2007 at 05:54:44PM -0400, Richard Stallman wrote:
>> If we put such messages at the end, that may cause the minibuffer
>> to grow by a line.  Would you find that disturbing?
>> 
>> If not, perhaps the thing to do is to put the message below the
>> current input, always growing the minibuffer.  Or put the message
>> above the minibuffer contents.  What would you think of that?
>
> Growing is not smooth.  If you grow to the top, the above line distracts you
> if you normally read text from top to bottom.  If you grow to the bottom, the
> original minibuffer line where you currently type in moves one line up.  So I
> would prefer to avoid growing the minibuffer whenever possible.  If the
> content wraps, then growing to the bottom as it is right now, is okay.
>
> A clean solution would be, to have messages concerning your current input
> (Mismatched parenthesis, ...) appear at the end of the minibuffer in
> brackets.

Right-justified?  And wrap the input before it when necessary?  That
would cause the least redisplay jitter, I would guess.

-- 
David Kastrup

Re: messages override minibuffer input

[Johannes Weiner]

[-- Attachment #1.1: Type: text/plain, Size: 719 bytes --]

Hi,

On Mon, Sep 24, 2007 at 01:12:37PM +0200, David Kastrup wrote:
> > A clean solution would be, to have messages concerning your current input
> > (Mismatched parenthesis, ...) appear at the end of the minibuffer in
> > brackets.
> 
> Right-justified?  And wrap the input before it when necessary?  That
> would cause the least redisplay jitter, I would guess.

Right-justified, yes.  And wrapping just the input, not the message?  This
wouldn't distract the user when a message appeared before the input wraps,
only when the input has to be wrapped at the moment a message appears.

Sounds good.  Other opinions on that, anybody?

	Hannes

-- 
3BD8 AF56 11AF 205C 9DB6  B10F 76F1 0634 71A4 DCA0

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: messages override minibuffer input

[Roland Winkler]

On Mon Sep 24 2007 Johannes Weiner wrote:
> Right-justified, yes.  And wrapping just the input, not the message?  This
> wouldn't distract the user when a message appeared before the input wraps,
> only when the input has to be wrapped at the moment a message appears.

Do you have in mind that messages are displayed temporarily, and
they disappear after a few seconds, though the minibuffer might
still be active? Or should messages remain visible for the whole
period of time the minibuffer is active? Depending on what one is
doing either way could minimize jitter of the minibuffer. So right
now I do not have a preference in one or the other direction.

If the message does not disappear again, what about multiple
messages? Should they accumulate somehow? That could make the
minibuffer grow significantly. So I would prefer to have not more
than one message being displayed (as usual).

Roland

RE: messages override minibuffer input

[Drew Adams]

>     [a line in the minibuffer] will wrap anyway if it is too long for
>     the window size.
>
> Do you mean wrap with fill at the fill column (by convention 70
> characters) or do you mean wrap without filling, which, on 80 column
> wide frames, may break a word between the 80 and 81 columns so the
> rest of the line can move down?

I meant what I see, which is the latter. Isn't that what you see?

Automatic filling would be inappropriate, as the echo area can contain stuff
that is not just natural-language words, and it is impossible to know where
to insert newlines appropriately. It might be inappropriate, for instance,
to insert a newline in the middle of a string echoed as part of a message -
e.g. `String: "foo bar"'.

RE: messages override minibuffer input

[Drew Adams]

> > > A clean solution would be, to have messages concerning your
> > > current input (Mismatched parenthesis, ...) appear at the end
> > > of the minibuffer in brackets.
> >
> > Right-justified?  And wrap the input before it when necessary?  That
> > would cause the least redisplay jitter, I would guess.
>
> Right-justified, yes.  And wrapping just the input, not the message?  This
> wouldn't distract the user when a message appeared before the input wraps,
> only when the input has to be wrapped at the moment a message appears.
>
> Sounds good.  Other opinions on that, anybody?

Yes, against. You are designing a complicated interface for a non-problem.
You will introduce more problems than those you think you see today. Code
cannot reasonably attempt to deal with all likely uses of the echo area in a
sophisticated DWIM fashion.

Please just leave it alone - it ain't broke.

Re: messages override minibuffer input

[Robert J. Chassell]

   I meant what I see, which [may break a word].  Isn't that what you
   see?

That is what I see when I invoke `display-message-or-buffer' with a
very long string as message.

However, since `resize-mini-windows' was invented, when the
information in the echo area displayed on more than one line, I 
think I have always seen it as properly filled for an 80 column 
frame but I may be wrong.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

RE: messages override minibuffer input

[Drew Adams]

>    I meant what I see, which [may break a word].  Isn't that what you
>    see?
>
> That is what I see when I invoke `display-message-or-buffer' with a
> very long string as message.
>
> However, since `resize-mini-windows' was invented, when the
> information in the echo area displayed on more than one line, I
> think I have always seen it as properly filled for an 80 column
> frame but I may be wrong.

I don't think I have ever seen such filling, but I too might be wrong. I
hope it is not currently filling and won't in the future fill.

Re: messages override minibuffer input

[Davis Herring]

>     You seem to say it has an important role to play, but I never found it
>     useful, and I always found it odd that autoloading displays such
>     messages while requiring a package doesn't.  What am I missing?
>
> I wasn't aware of that oddity, but now that you mention it,
> I don't see a need for them to be different.
> So we can turn off the messages for autoloading.

Really?  `require' happens during the loading of some other package, so
its delay is absorbed in the overall pause.  But autoloading an
arbitrarily complicated package (hi Alan! :) during a stream of user input
can look like a hang.  My suggestion is that all "Loading foo..." messages
should be displayed unconditionally, but then when "Loading foo...done"
would be displayed:
* if the minibuffer is in use, clear the echo area to restore it, else
* if the echo area previously had some non-optional message in it, restore
that message, else
* display it normally.

WDOT?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: messages override minibuffer input

[Drew Adams]

> My suggestion is that all "Loading foo..." messages
> should be displayed unconditionally, but then when "Loading foo...done"
> would be displayed:
> * if the minibuffer is in use, clear the echo area to restore it, else
> * if the echo area previously had some non-optional message in it, restore
>   that message, else
> * display it normally.
>
> WDOT?

Sounds good to me.

Re: messages override minibuffer input

[Richard Stallman]

    It appears more natural to me to put the message at the end than
    above the minibuffer contents.

Yes, but putting it at the end will require the minibuffer contents
lines to shift up.  Putting it at the beginning will allow those
lines to remain where they are.

Re: messages override minibuffer input

[Roland Winkler]

On Mon Sep 24 2007 Richard Stallman wrote:
> Yes, but putting it at the end will require the minibuffer contents
> lines to shift up.  Putting it at the beginning will allow those
> lines to remain where they are.

I see your point. Still it would appear odd and confusing to me if a
message "Mismatched parentheses" was displayed before the actual
text it refers to.

Roland

Re: messages override minibuffer input

[Richard Stallman]

    Right-justified?  And wrap the input before it when necessary?  That
    would cause the least redisplay jitter, I would guess.

That sounds good.

Re: messages override minibuffer input

[Richard Stallman]

    If the message does not disappear again, what about multiple
    messages? Should they accumulate somehow?

Emacs displays only the latest message.  The question is only how to
display it when the minibuffer is active.

Re: messages override minibuffer input

[Richard Stallman]

    Really?  `require' happens during the loading of some other package, so
    its delay is absorbed in the overall pause.  But autoloading an
    arbitrarily complicated package (hi Alan! :) during a stream of user input
    can look like a hang.

Nowadays it usually does not take very long.  For instance, visiting a
C file for the first time loads several Lisp files, and it takes less
than a second.  I don't think this needs to display messages.

Once upon a time, when GC could take a few seconds, GC displayed
messages too.  But when computers got faster, and GC took less time,
eventually the messages were more trouble than they were worth.
So I turned them off.

I don't want to implement anything complex in this area.