More visible mini-buffer prompt face

More visible mini-buffer prompt face

[Lennart Borgman (gmail)]

I do not know if I dare to make a suggestion right now. However this is 
a simple suggestion that will not break anything (except peoples mind 
perhaps ;-) ).

I have been working with some code using popup menus. That is a 
situation where I sometimes have to look at the popup menu and sometimes 
to the minibuffer. I noticed that even though I am quite used to Emacs 
now I sometimes am a bit slow to realize that Emacs is prompting me in 
the minibuffer.

I wonder if it would not be better to have a more visible face for the 
minibuffer prompt by default. My suggestion would be using a visible 
background color (some not too sharp yellow perhaps).

There is another situation where I also would prefer some more visible 
notice and that is when I get an error message and do not have enabled 
debug on error (this will be the normal user situation). I would prefer 
some colored face for the error messages too.

This is maybe the wrong time to suggest it. Or maybe it is not. The 
reason for my suggestion now is that Emacs way of displaying the things 
above is a bit surprising to new users. And a new release might 
encourage new users to try Emacs.

Is this something we can do? Is it useful at all?

Re: More visible mini-buffer prompt face

[Juanma Barranquero]

On 2/23/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> I wonder if it would not be better to have a more visible face for the
> minibuffer prompt by default. My suggestion would be using a visible
> background color (some not too sharp yellow perhaps).

>From etc/DEVEL.HUMOR:

  "In order to bring the user's attention to the minibuffer when an
item such as 'Edit -> Search' is activated from the menu, I was just
thinking that we could draw a big rectangle around the minibuffer,
blinking (or zooming in-and-out) until some input is typed in."
  "How about dancing elephants?"
  "They don't fit in my office."
  "Well once the elephants are done, your office will be much...
bigger."
                  -- Stefan Monnier, Miles Bader and Kai Grossjohann

             Juanma

Re: More visible mini-buffer prompt face

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 2/23/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
> 
>> I wonder if it would not be better to have a more visible face for the
>> minibuffer prompt by default. My suggestion would be using a visible
>> background color (some not too sharp yellow perhaps).
> 
>> From etc/DEVEL.HUMOR:
> 
>  "In order to bring the user's attention to the minibuffer when an
> item such as 'Edit -> Search' is activated from the menu, I was just
> thinking that we could draw a big rectangle around the minibuffer,
> blinking (or zooming in-and-out) until some input is typed in."
>  "How about dancing elephants?"
>  "They don't fit in my office."
>  "Well once the elephants are done, your office will be much...
> bigger."
>                  -- Stefan Monnier, Miles Bader and Kai Grossjohann
> 
>             Juanma


No problem. I am an African by heart.

Re: More visible mini-buffer prompt face

[Stefan Monnier]

>>> I wonder if it would not be better to have a more visible face for the
>>> minibuffer prompt by default. My suggestion would be using a visible
>>> background color (some not too sharp yellow perhaps).
>> 
>>> From etc/DEVEL.HUMOR:
>> 
>> "In order to bring the user's attention to the minibuffer when an
>> item such as 'Edit -> Search' is activated from the menu, I was just
>> thinking that we could draw a big rectangle around the minibuffer,
>> blinking (or zooming in-and-out) until some input is typed in."
>> "How about dancing elephants?"
>> "They don't fit in my office."
>> "Well once the elephants are done, your office will be much...
>> bigger."

> No problem. I am an African by heart.

Sorry but we only outsource to indian elephants.


        Stefan

Re: More visible mini-buffer prompt face

[Richard Stallman]

    I wonder if it would not be better to have a more visible face for the 
    minibuffer prompt by default. My suggestion would be using a visible 
    background color (some not too sharp yellow perhaps).

What color do you get now?
Which of the options in the defface is being used?
Could you propose a patch in that defface?

RE: More visible mini-buffer prompt face

[Drew Adams]

>     I wonder if it would not be better to have a more visible
>     face for the minibuffer prompt by default. My suggestion
>     would be using a visible background color (some not too
>     sharp yellow perhaps).
>
> What color do you get now?
> Which of the options in the defface is being used?
> Could you propose a patch in that defface?

I see no reason for the prompt to stand out more, and changing the
background color is a bad idea, IMO. Background colors are often used to
highlight particular sections of text, not just to present normal text. Why
should a normal _prompt_ stand out especially?

If your code pops up menus that attract the user away from the minibuffer,
and then you expect the user to notice a minibuffer prompt that you issue,
then why not make the minibuffer prompt stand out more _in your code_? This
sounds like a UI (dialog) problem in your code, not a problem with the
default Emacs minibuffer prompt face.

In general, minibuffer prompts appear when the user expects them; in fact,
they are usually initiated by the user. The case you describe, with the user
attention far from the minibuffer when a prompt appears out of the blue
there, is a special case, and it should be treated as such (in your code,
which defines that dialog). A normal prompt should not especially stand out;
the default prompt face that I see (dark blue) is fine.

Your point about error messages is different (independent). In that case,
the user might not expect to see stuff appear in the echo area, so you might
want to attract attention to it. Nothing prevents particular code from
applying text properties to messages in the echo area. That too is best left
up to the particular application, IMO. The default message face should not
stand out.

Re: More visible mini-buffer prompt face

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>     I wonder if it would not be better to have a more visible
>>     face for the minibuffer prompt by default. My suggestion
>>     would be using a visible background color (some not too
>>     sharp yellow perhaps).
>>
>> What color do you get now?
>> Which of the options in the defface is being used?
>> Could you propose a patch in that defface?

Thanks for constructive feedback.

> I see no reason for the prompt to stand out more, and changing the
> background color is a bad idea, IMO. Background colors are often used to
> highlight particular sections of text, not just to present normal text. Why
> should a normal _prompt_ stand out especially?

Because it needs the user attention.

> If your code pops up menus that attract the user away from the minibuffer,
> and then you expect the user to notice a minibuffer prompt that you issue,
> then why not make the minibuffer prompt stand out more _in your code_? This
> sounds like a UI (dialog) problem in your code, not a problem with the
> default Emacs minibuffer prompt face.

That is a good point. However I believe it is not just in the case of my 
code. The same problem appears in other cases within Emacs IMO.

> In general, minibuffer prompts appear when the user expects them; in fact,
> they are usually initiated by the user. 

I believe at least a new user does not expect the prompt sometimes. The 
reason for this is of course that the Emacs UI is different from w

> A normal prompt should not especially stand out;

Why not?

> Your point about error messages is different (independent). In that case,
> the user might not expect to see stuff appear in the echo area, so you might
> want to attract attention to it. Nothing prevents particular code from
> applying text properties to messages in the echo area.

I believe I did that before when using (message ...). However now it 
does not seem to work. Can you do it?

> That too is best left
> up to the particular application, IMO. The default message face should not
> stand out.

Yes, but I was talking about error messages.

RE: More visible mini-buffer prompt face

[Drew Adams]

> > I see no reason for the prompt to stand out more, and changing the
> > background color is a bad idea, IMO. Background colors are often used to
> > highlight particular sections of text, not just to present
> > normal text. Why should a normal _prompt_ stand out especially?
>
> Because it needs the user attention.

Why? The user should expect most prompts, no?

> > If your code pops up menus that attract the user away from the
> > minibuffer, and then you expect the user to notice a minibuffer
> > prompt that you issue, then why not make the minibuffer prompt
> > stand out more _in your code_? This sounds like a UI (dialog)
> > problem in your code, not a problem with the
> > default Emacs minibuffer prompt face.
>
> That is a good point. However I believe it is not just in the case of my
> code. The same problem appears in other cases within Emacs IMO.

Please be specific. In those cases also, the dialog should probably be
improved so the prompt is not unexpected. 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.

> > In general, minibuffer prompts appear when the user expects
> > them; in fact, they are usually initiated by the user.
>
> I believe at least a new user does not expect the prompt sometimes. The
> reason for this is of course that the Emacs UI is different from w

I think you got cut off there. But again, examples please of unexpected
prompts?

> > 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.

Some prompts are less expected, but I still don't see a reason to highlight
them. If I quit Emacs and I have unsaved buffers, Emacs asks me what I want
to do. I don't expect this question the first time, perhaps, but I still
notice it.

I'll admit that occasionally I don't notice the y-or-n question about
wanting to add a new line at the end of a file. But I wouldn't want Emacs to
ask any louder ;-).

In any case, questions that must have responses finish by making the user
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.

> > Your point about error messages is different (independent). In
> > that case, the user might not expect to see stuff appear in the
> > echo area, so you might want to attract attention to it. Nothing
> > prevents particular code from applying text properties to
> > messages in the echo area.
>
> I believe I did that before when using (message ...). However now it
> does not seem to work. Can you do it?

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

> > That too is best left up to the particular application, IMO.
> > The default message face should not stand out.
>
> Yes, but I was talking about error messages.

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.

The world has enough scary-or-exciting, flashing, red-and-yellow, tu-m'as-vu
messages that don't really need to be so flashy. Highlighting all warning
messages leads to "warning inflation": if everything is highlighted, then
nothing is highlighted.

Re: More visible mini-buffer prompt face

[Lennart Borgman (gmail)]

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?

RE: More visible mini-buffer prompt face

[Drew Adams]

Sorry, Lennart; I could only repeat myself - no new arguments.
I think we just disagree on this ;-).

Re: More visible mini-buffer prompt face

[Lennart Borgman (gmail)]

Drew Adams wrote:
> Sorry, Lennart; I could only repeat myself - no new arguments.
> I think we just disagree on this ;-).


No problem. I even think it is an important point. Why is it that hard 
to argue around UI issues? Or is it?

I believe it is. And I think it might have something to do with the 
mixing of logic and personal feelings. But for me that just make it more 
interesting.

Re: More visible mini-buffer prompt face

[Richard Stallman]

    I see no reason for the prompt to stand out more, and changing the

Until we know what colors he is getting now, it is premature to come
to any conclusions.

Re: More visible mini-buffer prompt face

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I see no reason for the prompt to stand out more, and changing the
>
> Until we know what colors he is getting now, it is premature to come
> to any conclusions.

The current colors have been unchanged since Aug 2005.
Any user who is unhappy with the default can just change the face.

Changing them now would be silly.
IMO there's no need to discuss this any further before the release.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: More visible mini-buffer prompt face

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     I wonder if it would not be better to have a more visible face for the 
>     minibuffer prompt by default. My suggestion would be using a visible 
>     background color (some not too sharp yellow perhaps).
> 
> What color do you get now?

Dark blue text on white.

> Which of the options in the defface is being used?
> Could you propose a patch in that defface?

The face used is minibuffer-prompt, see below. I have made a new 
suggestion for the default. This is modelled after secondary-selection 
face to avoid to big surprises. For light background this face has a 
yellow background. AFAIU yellow is often used to draw attention on 
different signs in our culture and that makes it a good choice here.

I selected a somewhat darker yellow variant of the named colors which I 
personally find more pleasant. Though I do not know if this color fits 
the (min-colors 88).

However it does not seem that the support for my idea is very big at the 
moment ;-)


Index: faces.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/faces.el,v
retrieving revision 1.366
diff -u -r1.366 faces.el
--- faces.el	14 Feb 2007 15:31:09 -0000	1.366
+++ faces.el	23 Feb 2007 20:14:56 -0000
@@ -2134,12 +2134,20 @@
    :version "22.1"
    :group 'basic-faces)

+;; Modelled after secondary-selection face.
+;; Suggested on Emacs Devel as usual.
  (defface minibuffer-prompt
-  '((((background dark)) :foreground "cyan")
-    ;; Don't use blue because many users of the MS-DOS port customize
-    ;; their foreground color to be blue.
-    (((type pc)) :foreground "magenta")
-    (t :foreground "dark blue"))
+  '((((class color) (min-colors 88) (background light))
+     :background "gold")
+    (((class color) (min-colors 88) (background dark))
+     :background "SkyBlue4")
+    (((class color) (min-colors 16) (background light))
+     :background "yellow")
+    (((class color) (min-colors 16) (background dark))
+     :background "SkyBlue4")
+    (((class color) (min-colors 8))
+     :background "cyan" :foreground "black")
+    (t :inverse-video t))
    "Face for minibuffer prompts.
  By default, Emacs automatically adds this face to the value of
  `minibuffer-prompt-properties', which is a list of text properties

Re: More visible mini-buffer prompt face

[Daniel Brockman]

    +  '((((class color) (min-colors 88) (background light))
    +     :background "gold")

I'm sorry, but I think this just doesn't look good.

At the very least, IMHO, you'd have to add a space to the
beginning of the prompt (or remove the one at the end) so
that there would be as much yellow padding to the left of
the prompt as there is to the right.

-- 
Daniel Brockman <daniel@brockman.se>

Re: More visible mini-buffer prompt face

[Lennart Borgman (gmail)]

Daniel Brockman wrote:
>     +  '((((class color) (min-colors 88) (background light))
>     +     :background "gold")
> 
> I'm sorry, but I think this just doesn't look good.
> 
> At the very least, IMHO, you'd have to add a space to the
> beginning of the prompt (or remove the one at the end) so
> that there would be as much yellow padding to the left of
> the prompt as there is to the right.

Yes, that is a little problem. Maybe the space to the left (the fringe) 
can be made the same color? I have no idea if that is easy or not however.

Re: More visible mini-buffer prompt face

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> The face used is minibuffer-prompt, see below. I have made a new 
> suggestion for the default. This is modelled after secondary-selection 

Those changed background colors just don't look very good.

Really, there's nothing wrong with the current defaults.  If a
particular user has problems realizing he's being prompted, he can of
course tweak the face to suit himself.

[I mostly use dark-background, but the current default there is quite
nice, I think.]

-Miles

-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: More visible mini-buffer prompt face

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 24 Feb 2007 23:20:47 +0900
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> Really, there's nothing wrong with the current defaults.  If a
> particular user has problems realizing he's being prompted, he can of
> course tweak the face to suit himself.
> 
> [I mostly use dark-background, but the current default there is quite
> nice, I think.]

And, given the amount of time and testing they took on various
displays and color depths, now is definitely not the time to argue
about changing those current defaults.

Re: More visible mini-buffer prompt face

[Richard Stallman]

    Dark blue text on white.

That's what I get.  It seems quite visible to me.
Why isn't that visible for you?

Re: More visible mini-buffer prompt face

[Richard Stallman]

    > What color do you get now?

    Dark blue text on white.

I agree that is hard to distinguish from ordinary black-on-white text.
The blue needs to be more different from black.

What would you think of using `medium blue'?

Re: More visible mini-buffer prompt face

[Mathias Dahl]

> I agree that is hard to distinguish from ordinary black-on-white text.
> The blue needs to be more different from black.
>
> What would you think of using `medium blue'?

If the point is to make it easier to distinguish the prompt itself from the
text the user enters, this is better, IMO. But if the point was to
make the prompt
more visible when the user is looking somewhere else in the frame, I'd say
that it doesn't make much difference in getting his attention.

Re: More visible mini-buffer prompt face

[Lennart Borgman (gmail)]

Mathias Dahl wrote:
>> I agree that is hard to distinguish from ordinary black-on-white text.
>> The blue needs to be more different from black.
>>
>> What would you think of using `medium blue'?
> 
> If the point is to make it easier to distinguish the prompt itself from the
> text the user enters, this is better, IMO. But if the point was to
> make the prompt
> more visible when the user is looking somewhere else in the frame, I'd say
> that it doesn't make much difference in getting his attention.

Yes, that is right. I was thinking of the second scenario here (ie the 
user is looking somewhere else). I sent a suggestion as a patch to the 
list in this message:

   http://lists.gnu.org/archive/html/emacs-devel/2007-02/msg01071.html

This also includes a bug fix for the customize part of the 
initialization of minibuffer-prompt-properties.

Re: More visible mini-buffer prompt face

[Richard Stallman]

    If the point is to make it easier to distinguish the prompt itself from the
    text the user enters, this is better, IMO. But if the point was to
    make the prompt
    more visible when the user is looking somewhere else in the frame, I'd say
    that it doesn't make much difference in getting his attention.

I see your point.  But I hesitate to make a change in the background
color, especially now.  So I will just change it to medium blue.

Re: More visible mini-buffer prompt face

[Mathias Dahl]

> I wonder if it would not be better to have a more visible face for
> the minibuffer prompt by default. My suggestion would be using a
> visible background color (some not too sharp yellow perhaps).

 I think that I understand the reason for you wanting this; I
sometimes miss the prompt at first, for example the prompt that is
displayed when trying to update a buffer who's file has been updated
on disk. I think that there are a couple of other situations as well,
but I don't remember any right now.

 I think the biggest problem here is that we use the same prompt for
so many different things. In most cases (one can hope), the prompt is
expected as a result of the user executing a certain command (M-x, C-s
or whatever). In some cases it is not expected.

 But! This differs from person to person! Let's say I am a new user
that never use isearch; instead I use the Edit -> Search -> String
Forward command. If I accidently hit C-s (maybe I missed a key when
doing C-a) I might not be expecting the prompt.  The question is;
would this situation be "important" enough to justify a more visible
prompt? I think this is *the* problem, all user expects different
things because they use the program in differen ways and with
different experience.

 What we can, and should do, in my opinion, is make sure that nothing
"bad" happens if the user at first does not see the prompt, if he just
keeps tpying away. There might be cases like that (I haven't though
about it), and we might want to try and fix those to work better.

About prompts in general:

 I happen to agree with the ideas of the late Jef Raskin, when it
comes to prompting the user. Especially in the Yes/No scenario. If you
display this kind of prompt too much, the user will form a habit of
always answering Yes (I think that the most common case).  What
happens next is that there is this Yes/No prompt, to which the user
wants to answer No, if he had stopped for a moment and thought about
it, but instead he chose Yes, because he has formed a habit of doing
so.

 When this happens, the prompt has more or less lost its meaning. The
alternative to doing this is to not prompt, and instead display a
non-intrusive, but visible, informational message, about what just
happened, and provide good Undo functionality so that the user can
revert the (potentially) destructive operation. In a perfect world
this would be possible to have Undo for everything, but today there
are some situations where this isn't practically possible, so I guess
we have to live with these prompts and dialog boxes for a while...

My 0.2 kroner.

Re: More visible mini-buffer prompt face

[Lennart Borgman (gmail)]

Mathias Dahl wrote:
>> I wonder if it would not be better to have a more visible face for
>> the minibuffer prompt by default. My suggestion would be using a
>> visible background color (some not too sharp yellow perhaps).
> 
> I think that I understand the reason for you wanting this; I
> sometimes miss the prompt at first, for example the prompt that is
> displayed when trying to update a buffer who's file has been updated
> on disk. I think that there are a couple of other situations as well,
> but I don't remember any right now.
...
> But! This differs from person to person!


Another approach to this would be to give a more visible prompt as a 
standard option. It is quite easy to add an alternative in the options 
menu for this. I think it would fit very well below or above "Blinking 
Cursor" since it has kind of the same spirit.

So I would suggest something in the menubar like "Options - More 
Noticeable Prompt" below "Blinking Cursor".

Or, maybe just "Customize Prompt Face".

Re: More visible mini-buffer prompt face

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> Mathias Dahl wrote:
>>> I wonder if it would not be better to have a more visible face for
>>> the minibuffer prompt by default. My suggestion would be using a
>>> visible background color (some not too sharp yellow perhaps).
>>
>> I think that I understand the reason for you wanting this; I
>> sometimes miss the prompt at first, for example the prompt that is
>> displayed when trying to update a buffer who's file has been updated
>> on disk. I think that there are a couple of other situations as well,
>> but I don't remember any right now.
> ...
>> But! This differs from person to person!
> 
> 
> Another approach to this would be to give a more visible prompt as a 
> standard option. It is quite easy to add an alternative in the options 
> menu for this. I think it would fit very well below or above "Blinking 
> Cursor" since it has kind of the same spirit.
> 
> So I would suggest something in the menubar like "Options - More 
> Noticeable Prompt" below "Blinking Cursor".
> 
> Or, maybe just "Customize Prompt Face".


Here is a patch for that suggestion (it also includes a bug fix):



Index: menu-bar.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/menu-bar.el,v
retrieving revision 1.301
diff -u -r1.301 menu-bar.el
--- menu-bar.el	21 Jan 2007 03:53:11 -0000	1.301
+++ menu-bar.el	25 Feb 2007 18:48:15 -0000
@@ -973,6 +973,10 @@
  (define-key menu-bar-options-menu [debugger-separator]
    '("--"))

+(define-key menu-bar-options-menu [toggle-noticeable-minibuffer-prompt]
+  (menu-bar-make-mm-toggle noticeable-minibuffer-prompts-mode
+                           "More Noticeable Prompt"
+                           "Whether minibuffer prompts gets a more 
noticeable face"))
  (define-key menu-bar-options-menu [blink-cursor-mode]
    (menu-bar-make-mm-toggle blink-cursor-mode
  			   "Blinking Cursor"
@@ -1769,6 +1773,19 @@
  			 "Menu-bar mode disabled.  Use M-x menu-bar-mode to make the menu 
bar appear."))
    menu-bar-mode)

+(define-minor-mode noticeable-minibuffer-prompts-mode
+  "Use a more noticeable minibuffer prompt face when this mode is on.
+Turning this mode on changes the face used for minibuffer prompts to
+`minibuffer-noticeable-prompt'.  Turning it off changes it to
+`minibuffer-prompt'."
+ :init-value t
+ :global t
+ :group 'basic-faces
+ (let ((face (member 'face minibuffer-prompt-properties)))
+   (if noticeable-minibuffer-prompts-mode
+       (setcar (cdr face) 'minibuffer-noticeable-prompt)
+     (setcar (cdr face) 'minibuffer-prompt))))
+
  (provide 'menu-bar)

  ;;; arch-tag: 6e6a3c22-4ec4-4d3d-8190-583f8ef94ced



Index: faces.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/faces.el,v
retrieving revision 1.366
diff -u -r1.366 faces.el
--- faces.el	14 Feb 2007 15:31:09 -0000	1.366
+++ faces.el	25 Feb 2007 19:54:19 -0000
@@ -2143,12 +2143,36 @@
    "Face for minibuffer prompts.
  By default, Emacs automatically adds this face to the value of
  `minibuffer-prompt-properties', which is a list of text properties
-used to display the prompt text."
+used to display the prompt text.
+
+See also `minibuffer-noticeable-prompt'."
+  :version "22.1"
+  :group 'basic-faces)
+
+;; Modelled after secondary-selection face.
+;; Suggested on Emacs Devel as usual.
+(defface minibuffer-noticeable-prompt
+  '((((class color) (min-colors 88) (background light))
+     :background "gold")
+    (((class color) (min-colors 88) (background dark))
+     :background "SkyBlue4")
+    (((class color) (min-colors 16) (background light))
+     :background "yellow")
+    (((class color) (min-colors 16) (background dark))
+     :background "SkyBlue4")
+    (((class color) (min-colors 8))
+     :background "cyan" :foreground "black")
+    (t :inverse-video t))
+  "More noticeable face for minibuffer prompts.
+You can switch between using this face and the face
+`minibuffer-prompt' for the minibuffer prompt with the function
+`toggle-noticeable-minibuffer-prompts'."
    :version "22.1"
    :group 'basic-faces)

  (setq minibuffer-prompt-properties
-      (append minibuffer-prompt-properties (list 'face 
'minibuffer-prompt)))
+      (append minibuffer-prompt-properties (list 'face 
'minibuffer-noticeable-prompt)))
+(put 'minibuffer-prompt-properties 'standard-value (list (list 'quote 
minibuffer-prompt-properties)))

  (defface fringe
    '((((class color) (background light))

Re: More visible mini-buffer prompt face

[Richard Stallman]

     What we can, and should do, in my opinion, is make sure that nothing
    "bad" happens if the user at first does not see the prompt, if he just
    keeps tpying away. There might be cases like that (I haven't though
    about it), and we might want to try and fix those to work better.

How could that be even conceivable?  The prompt means that you have
temporarily entered a special mode in which your input has a different
meaning.  If you type as if you didn't know you had entered the
minibuffer, it has to be misunderstood.

The only way this COULD not be the case is if we had different
characters for the minibuffer.  For instance, if the characters you
used to type a search string were different from the ones that you use
while doing ordinary editing.  But that would be very inconvenient,
given the hardware and software environment that exists.

     I happen to agree with the ideas of the late Jef Raskin, when it
    comes to prompting the user. Especially in the Yes/No scenario. If you
    display this kind of prompt too much, the user will form a habit of
    always answering Yes (I think that the most common case).

The question of when to ask for confirmation, and how, is an important
one, but it isn't the same one.  In Emacs, the reason we have
both y-or-n-p and yes-or-no-p is partly to address this.

Re: More visible mini-buffer prompt face

[Mathias Dahl]

> The question of when to ask for confirmation, and how, is an important
> one, but it isn't the same one.  In Emacs, the reason we have
> both y-or-n-p and yes-or-no-p is partly to address this.

I know it is off-topic, but could you elaborate on this one (or is it
maybe in the
manual... I'll have a look)?
Do you refer to the fact that you have to type the more "difficult"
string "yes" + enter,
instead of just typing "y"? In my case I often do arrow-up + enter, because in
99 cases of 100, the last response I made was "yes", so it does not
really make it
much harder for me to do something wrong (because I am forming a habit).

Re: More visible mini-buffer prompt face

[Richard Stallman]

    Do you refer to the fact that you have to type the more "difficult"
    string "yes" + enter,
    instead of just typing "y"?

Yes.

				In my case I often do arrow-up + enter, because in
    99 cases of 100, the last response I made was "yes", so it does not
    really make it
    much harder for me to do something wrong (because I am forming a habit).

I suggest you stop that practice.

Re: More visible mini-buffer prompt face

[Mathias Dahl]

>                                In my case I often do arrow-up + enter, because in
>    99 cases of 100, the last response I made was "yes", so it does not
>    really make it
>    much harder for me to do something wrong (because I am forming a habit).
>
> I suggest you stop that practice.

Haha, okay... :)

Seriously, if we write a program where certain habits often form for the users,
I don't think it is the user's fault.

However, it does not feel like this is the right thread, or time, to
discuss these, sometimes philosophical, matters...

Re: More visible mini-buffer prompt face

[Juanma Barranquero]

On 2/26/07, Mathias Dahl <mathias.dahl@gmail.com> wrote:

> Seriously, if we write a program where certain habits often
> form for the users, I don't think it is the user's fault.

Why not? In other aspects of life it is often the case that bad habits
are the user's fault (no one would blame the car for the user driving
under the influence of alcohol).

Seriously, if a program asks you to type "yes" and press RETURN to
confirm a possibly dangerous action, and you do look for ways to
automatize skipping the question... what more could the program do?
Isn't that obnoxious enough? Do we start an arms race between prompts
and users?

The answer given before ("do not prompt, let him do it and provide
ways to undo") is good, but not always applicable.

> However, it does not feel like this is the right thread, or time, to
> discuss these, sometimes philosophical, matters...

Oops. :)

             Juanma

Re: More visible mini-buffer prompt face

[Mathias Dahl]

> Seriously, if a program asks you to type "yes" and press RETURN to
> confirm a possibly dangerous action, and you do look for ways to
> automatize skipping the question... what more could the program do?

I think that part of the problem is that different people have
different opinions
on what a "dangerous" action is (See the previous thread about image auto
detection for a good example... :)), and maybe we sometimes out of laziness take
the easy way out and provide a Yes/No prompt, instead of thinking one
extra time.

(Btw, about the "yes/no" prompt, why do we provide minibuffer history there if
we want to make it harder for the user to dismiss the prompt?)

I would like to recommend trying out having a "kill key" in Emacs. I have bound
a command to F5 that tries to kill the current buffer. If the buffer
has no changes
it will work, if it has unsaved changes, Emacs will beep, with an
error. But, this is
important, I get no prompt, so I cannot by mistake type that "yes" +
RET (bad habit).
Instead I have to stop and think a bit and decide to do a C-x k RET y e s RET
(or, save first and then use F5). Yes, slightly annoying the times where I have
unsaved changes, but most of the time much nicer as I can kill a buffer with a
single keypress.

> Do we start an arms race between prompts and users?

No, oh please no! We try not to get into such a race at all.

> The answer given before ("do not prompt, let him do it and provide
> ways to undo") is good, but not always applicable.

True, unfortunately.  But we should try.

> > However, it does not feel like this is the right thread, or time, to
> > discuss these, sometimes philosophical, matters...
>
> Oops. :)

Oops x 2 :)

Re: More visible mini-buffer prompt face

[Stuart D. Herring]

> 				In my case I often do arrow-up + enter, because in
>     99 cases of 100, the last response I made was "yes", so it does not
>     really make it
>     much harder for me to do something wrong (because I am forming a
> habit).
>
> I suggest you stop that practice.

I'd like to recommend this for DEVEL.HUMOR.

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.