unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: emacs-devel@gnu.org
Subject: Re: More visible mini-buffer prompt face
Date: Sat, 24 Feb 2007 02:01:27 +0100	[thread overview]
Message-ID: <45DF8E67.3050603@gmail.com> (raw)
In-Reply-To: <EIENLHALHGIMHGDOLMIMEECMCPAA.drew.adams@oracle.com>

Drew Adams wrote:
> Why? The user should expect most prompts, no?


It depends on several things. Sometimes Emacs prompts you unexpectedly 
as you have noticed in the example you gave with the line endings.

Sometimes it may be the structure of interaction. If you use some kind 
of "template" there may be different number of questions at different 
times. There may also be a mix of popup menus and minibuffer prompts. 
(That mix may be unavoidable to a certain part depending on what you 
want to do.)


> Please be specific. In those cases also, the dialog should probably be
> improved so the prompt is not unexpected.


On such case is when quitting ediff. Other cases is when you have got an 
unexpected prompt and then happen to switch frame before you notice it. 
(I would like some notice also on the other frames here, but that seems 
to much to do right now.)


> Or, if it must be unexpected, then
> temporarily use a different face or `ding' or whatever, if it's thought that
> users won't notice it.


The notification should be specific since the UI is a bit unusual to new 
users.


>>> A normal prompt should not especially stand out;
>> Why not?
> 
> Because the user expects it, looks for it. If I initiate query-replace, I
> expect that the program will ask me what to replace with what? If I initiate
> go-to-line, I expect that the program will ask me which line.


I remember I was quite surprised in the beginning of how Emacs prompted. 
It took some time to really get used to it.


> But I wouldn't want Emacs to ask any louder ;-).


The face of the minibuffer prompt is customizable. So it is quite easy 
for you as an experienced user to get rid of it if you do not want it.

The reverse is not true. It is much harder for a new user to make the 
prompt louder.


> notice them, one way or the other. The point is that there is no reason to
> make them more intrusive (LOUDER) all of the time, because they can make
> themselves be noticed when they need to.


My point is in the other direction. Be consistent in the UI. A prompt is 
always a prompt in that sense we are talking about it now. It needs the 
users attention.

Then there might be other times when the answer is more "serious". It 
kind of goes against my argument here of course, but I still think a 
more visual default prompt has advantages.


> Haven't tried lately, but I believe this is a new feature in Emacs 22. If it
> doesn't work, please file a bug.


I tried and failed. But maybe I misremembered something.

> By default, `error' messages shouldn't stand out either, IMO. If a
> particular error message really needs to grab the user's attention, there
> are ways of doing that.


Should not error messages be reserved for the case when the users 
attention is needed more than for just a warning or an informational 
message?

  reply	other threads:[~2007-02-24  1:01 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-23 16:24 More visible mini-buffer prompt face Lennart Borgman (gmail)
2007-02-23 16:41 ` Juanma Barranquero
2007-02-23 17:46   ` Lennart Borgman (gmail)
2007-02-23 18:09     ` Stefan Monnier
2007-02-23 19:36 ` Richard Stallman
2007-02-23 19:58   ` Drew Adams
2007-02-23 21:47     ` Lennart Borgman (gmail)
2007-02-24  0:18       ` Drew Adams
2007-02-24  1:01         ` Lennart Borgman (gmail) [this message]
2007-02-24  1:08           ` Drew Adams
2007-02-24  1:27             ` Lennart Borgman (gmail)
2007-02-24  8:28     ` Richard Stallman
2007-02-24 22:16       ` Kim F. Storm
2007-02-24  1:35   ` Lennart Borgman (gmail)
2007-02-24  4:30     ` Daniel Brockman
2007-02-24 18:51       ` Lennart Borgman (gmail)
2007-02-24 14:20     ` Miles Bader
2007-02-24 14:36       ` Eli Zaretskii
2007-02-25  4:06     ` Richard Stallman
2007-02-26  3:27     ` Richard Stallman
2007-02-26 10:55       ` Mathias Dahl
2007-02-26 16:48         ` Lennart Borgman (gmail)
2007-02-27  7:38         ` Richard Stallman
2007-02-24 17:58 ` Mathias Dahl
2007-02-25  1:09   ` Lennart Borgman (gmail)
2007-02-25 20:44     ` Lennart Borgman (gmail)
2007-02-25  4:06   ` Richard Stallman
2007-02-25 11:01     ` Mathias Dahl
2007-02-26  3:27       ` Richard Stallman
2007-02-26 10:45         ` Mathias Dahl
2007-02-26 11:20           ` Juanma Barranquero
2007-02-26 23:53             ` Mathias Dahl
2007-02-27 19:07         ` Stuart D. Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45DF8E67.3050603@gmail.com \
    --to=lennart.borgman@gmail.com \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).