bug#21112: 25; Patch: show minibuffer messages with a face

bug#21112: 25; Patch: show minibuffer messages with a face

[Raffaele Ricciardi]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

Dear GNU Emacs maintainers,

this patch against the Git repository makes the minibuffer messages
appear with the same face as the minibuffer prompt, to make them more
visually distinguished from user input.

Thanks for your attention.
Best Regards

[-- Attachment #2: 0001-minibuffer.el-Make-minibuffer-message-use-minibuffer.patch --]
[-- Type: text/x-patch, Size: 974 bytes --]

From 37292a9cbe5ac7c19ee6ef273fca977105487b37 Mon Sep 17 00:00:00 2001
From: Raffaele Ricciardi <deleted@for.privacy>
Date: Mon, 20 Jul 2015 00:11:03 +0200
Subject: [PATCH] * minibuffer.el: Make 'minibuffer-message' use the
 'minibuffer-prompt' face.

---
 lisp/minibuffer.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 411416b..ac1b660 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -703,6 +703,7 @@ If ARGS are provided, then pass MESSAGE through `format'."
                       (copy-sequence message)
                     (concat " [" message "]")))
     (when args (setq message (apply 'format message args)))
+    (setq message (propertize message 'face 'minibuffer-prompt))
     (let ((ol (make-overlay (point-max) (point-max) nil t t))
           ;; A quit during sit-for normally only interrupts the sit-for,
           ;; but since minibuffer-message is used at the end of a command,
-- 
2.1.4

bug#21112: 25; Patch: show minibuffer messages with a face

[Drew Adams]

> this patch against the Git repository makes the minibuffer messages
> appear with the same face as the minibuffer prompt, to make them
> more visually distinguished from user input.

FWIW, I hope this does not get applied in general.

Currently, *users* have control over the faces used in message
echoes.  It should remain that way.  It is trivial for user code
to control the output appearance now.  Let's not mess this up.

In fact, we should not even apply a face by default to the prompt.
That was a step backward (misguided), IMHO.  If a user (or library)
wants something different (other than customizing the prompt face,
which still gives the same appearance to the whole prompt), then
s?he now needs to fiddle.

Shouldn't be necessary.  We should have just left things
unhighlighted by default, letting users themselves (again,
trivially) propertize the prompt string any way they want.

Doing the kind of thing suggested by this enhancement request
does not add a feature.  It takes away a feature.  We already,
everyone, have the ability to propertize messages in any way
we like.  If you want them all to have face `minibuffer-prompt'
then you can accomplish that trivially - for your own use.

bug#21112: 25; Patch: show minibuffer messages with a face

[Drew Adams]

I haven't looked at the patch, and I misread the request as applying
to `message' output, not `minibuffer-message'.  But I have the same
response in the latter case - leave it alone, so users can do with
it what they like.

bug#21112: 25; Patch: show minibuffer messages with a face

[Raffaele Ricciardi]

On 22/07/15 15:44, Drew Adams wrote:
> I haven't looked at the patch, and I misread the request as applying
> to `message' output, not `minibuffer-message'. But I have the same
> response in the latter case - leave it alone, so users can do with
> it what they like.

I understand what you mean and I agree when you say that the current
implementation is more flexible.  The problem that this patch tries to
solve is that -- as far as I can see -- all Emacs messages are
currently passed as plain strings, and thus appear in the same face as
user input, making it seem that Emacs is meddling with user input,
which is not the case.  Now, requiring callers to specify a face for
every single message would be burdensome, wouldn't it?  Maybe, could
we make `minibuffer-message' apply the `minibuffer-prompt' face only
if the message lacks its own faces?  Or maybe, could we split
`minibuffer-message' in two functions, one -- internal -- that applies
the `minibuffer-prompt' face and one that doesn't?  The same approach
could be applied to the minibuffer prompt, too.

bug#21112: 25; Patch: show minibuffer messages with a face

[Drew Adams]

> > I haven't looked at the patch, and I misread the request as
> applying
> > to `message' output, not `minibuffer-message'. But I have the same
> > response in the latter case - leave it alone, so users can do with
> > it what they like.
> 
> I understand what you mean and I agree when you say that the current
> implementation is more flexible.  The problem that this patch tries
> to
> solve is that -- as far as I can see -- all Emacs messages are
> currently passed as plain strings, and thus appear in the same face
> as
> user input, making it seem that Emacs is meddling with user input,
> which is not the case.  Now, requiring callers to specify a face for
> every single message would be burdensome, wouldn't it?  Maybe, could
> we make `minibuffer-message' apply the `minibuffer-prompt' face only
> if the message lacks its own faces?  Or maybe, could we split
> `minibuffer-message' in two functions, one -- internal -- that
> applies
> the `minibuffer-prompt' face and one that doesn't?  The same
> approach
> could be applied to the minibuffer prompt, too.

I hear you, but I would (still) say leave it alone.

It is not just that the string that might already have faces.
A user can have a standalone minibuffer with a default face, etc.

YAGNI - my 2 cents

bug#21112: 25; Patch: show minibuffer messages with a face

[Lars Ingebrigtsen]

Raffaele Ricciardi <rfflrccrd@gmail.com> writes:

> Dear GNU Emacs maintainers,
>
> this patch against the Git repository makes the minibuffer messages
> appear with the same face as the minibuffer prompt, to make them more
> visually distinguished from user input.

[...]

>      (when args (setq message (apply 'format message args)))
> +    (setq message (propertize message 'face 'minibuffer-prompt))

I think it might be a good idea to use a different face for these
temporary messages, but you can currently do this:

(minibuffer-message (propertize "Foo" 'face 'bold))

And overwriting the specified face isn't a good idea.  But perhaps it
could apply a default face to the string if no face has already been
set?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#21112: 25; Patch: show minibuffer messages with a face

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>>      (when args (setq message (apply 'format message args)))
>> +    (setq message (propertize message 'face 'minibuffer-prompt))
>
> I think it might be a good idea to use a different face for these
> temporary messages, but you can currently do this:
>
> (minibuffer-message (propertize "Foo" 'face 'bold))

So I don't think this is something that we want; closing the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#21112: 25; Patch: show minibuffer messages with a face

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

>>>      (when args (setq message (apply 'format message args)))
>>> +    (setq message (propertize message 'face 'minibuffer-prompt))
>>
>> I think it might be a good idea to use a different face for these
>> temporary messages, but you can currently do this:
>>
>> (minibuffer-message (propertize "Foo" 'face 'bold))
>
> So I don't think this is something that we want; closing the bug report.

For consistency with isearch messages that are highlighted with the
minibuffer-prompt face, minibuffer-message needs to do the same.

But since a message is displayed at different part of the minibuffer,
it should be highlighted using a new separate customizable variable
similar to minibuffer-prompt-properties:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: minibuffer-message-properties.patch --]
[-- Type: text/x-diff, Size: 2465 bytes --]

diff --git a/lisp/isearch.el b/lisp/isearch.el
index bb29c2914b..b527a210ac 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -1996,7 +1996,7 @@ isearch--momentary-message
     (message "%s%s%s"
              (isearch-message-prefix nil isearch-nonincremental)
              isearch-message
-             (propertize (format " [%s]" string) 'face 'minibuffer-prompt)))
+             (apply #'propertize (format " [%s]" string) minibuffer-message-properties)))
   (sit-for 1))
 
 (isearch-define-mode-toggle lax-whitespace " " nil
@@ -3200,18 +3200,18 @@ isearch-message-prefix
 			(concat " [" current-input-method-title "]: "))
 		     ": ")
 		   )))
-    (propertize (concat (isearch-lazy-count-format)
+    (apply #'propertize (concat (isearch-lazy-count-format)
                         (upcase (substring m 0 1)) (substring m 1))
-		'face 'minibuffer-prompt)))
+	   minibuffer-message-properties)))
 
 (defun isearch-message-suffix (&optional c-q-hack)
-  (propertize (concat (if c-q-hack "^Q" "")
+  (apply #'propertize (concat (if c-q-hack "^Q" "")
 		      (isearch-lazy-count-format 'suffix)
 		      (if isearch-error
 			  (concat " [" isearch-error "]")
 			"")
 		      (or isearch-message-suffix-add ""))
-	      'face 'minibuffer-prompt))
+	 minibuffer-message-properties))
 
 (defun isearch-lazy-count-format (&optional suffix-p)
   "Format the current match number and the total number of matches.
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 57702760fb..5f3986697b 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -693,6 +693,9 @@ minibuffer
   :link '(custom-manual "(emacs)Minibuffer")
   :group 'environment)
 
+(defvar minibuffer-message-properties minibuffer-prompt-properties
+  "Text properties that are added to minibuffer messages.")
+
 (defun minibuffer-message (message &rest args)
   "Temporarily display MESSAGE at the end of the minibuffer.
 The text is displayed for `minibuffer-message-timeout' seconds,
@@ -714,6 +717,7 @@ minibuffer-message
                       (copy-sequence message)
                     (concat " [" message "]")))
     (when args (setq message (apply #'format-message message args)))
+    (setq message (apply #'propertize message minibuffer-message-properties))
     (let ((ol (make-overlay (point-max) (point-max) nil t t))
           ;; A quit during sit-for normally only interrupts the sit-for,
           ;; but since minibuffer-message is used at the end of a command,

bug#21112: 25; Patch: show minibuffer messages with a face

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>>> I think it might be a good idea to use a different face for these
>>> temporary messages, but you can currently do this:
>>>
>>> (minibuffer-message (propertize "Foo" 'face 'bold))
>>
>> So I don't think this is something that we want; closing the bug report.
>
> For consistency with isearch messages that are highlighted with the
> minibuffer-prompt face, minibuffer-message needs to do the same.

[...]

> +    (setq message (apply #'propertize message minibuffer-message-properties))

But this will overwrite the face properties the caller has set, right?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#21112: 25; Patch: show minibuffer messages with a face

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

>>>> I think it might be a good idea to use a different face for these
>>>> temporary messages, but you can currently do this:
>>>>
>>>> (minibuffer-message (propertize "Foo" 'face 'bold))
>>>
>>> So I don't think this is something that we want; closing the bug report.
>>
>> For consistency with isearch messages that are highlighted with the
>> minibuffer-prompt face, minibuffer-message needs to do the same.
>
> [...]
>
>> +    (setq message (apply #'propertize message minibuffer-message-properties))
>
> But this will overwrite the face properties the caller has set, right?

This patch checks for existing face properties to not overwrite them:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: minibuffer-message-properties.3.patch --]
[-- Type: text/x-diff, Size: 757 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 57702760fb..9a473b6867 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -714,6 +717,9 @@ minibuffer-message
                       (copy-sequence message)
                     (concat " [" message "]")))
     (when args (setq message (apply #'format-message message args)))
+    ;; If not already propertized:
+    (unless (or (text-properties-at 0 message) (next-property-change 0 message))
+      (setq message (apply #'propertize message minibuffer-message-properties)))
     (let ((ol (make-overlay (point-max) (point-max) nil t t))
           ;; A quit during sit-for normally only interrupts the sit-for,
           ;; but since minibuffer-message is used at the end of a command,

bug#21112: 25; Patch: show minibuffer messages with a face

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> This patch checks for existing face properties to not overwrite them:

I'm not really convinced that there should be any face properties on the
minibuffer messages at all, though.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#21112: 25; Patch: show minibuffer messages with a face

[Drew Adams]

> I'm not really convinced that there should be any face properties on the
> minibuffer messages at all, though.  :-)

Yes, and a caller can always add whatever properties
it wants/needs.  It's not hard to pass a propertized
string to `minibuffer-message'.

At any rate, if we do provide for properties in some
way, it needs to be easy for a user or calling code
to control the properties.  It not kosher to hard-code
properties for such things.

bug#21112: 25; Patch: show minibuffer messages with a face

[Juri Linkov]

>> I'm not really convinced that there should be any face properties on the
>> minibuffer messages at all, though.  :-)
>
> Yes, and a caller can always add whatever properties
> it wants/needs.  It's not hard to pass a propertized
> string to `minibuffer-message'.

It makes no sense for a caller of a particular command
to decide whether to highlight the message or not.

It should be user's preference whether to highlight
all messages from all commands, or none at all.

If the user decided "I don't want caller's highlighting",
a caller should not have the right to override user's preference.

So we should not allow a caller to overwrite the default
face properties, and I retract that part of my previous patch.

This is a better patch that uses caller's properties
only when minibuffer-message-properties is nil:

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 57702760fb..fa45616bf3 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -693,6 +693,9 @@ minibuffer
   :link '(custom-manual "(emacs)Minibuffer")
   :group 'environment)
 
+(defvar minibuffer-message-properties minibuffer-prompt-properties
+  "Text properties added to the text shown by `minibuffer-message'.")
+
 (defun minibuffer-message (message &rest args)
   "Temporarily display MESSAGE at the end of the minibuffer.
 The text is displayed for `minibuffer-message-timeout' seconds,
@@ -714,6 +717,8 @@ minibuffer-message
                       (copy-sequence message)
                     (concat " [" message "]")))
     (when args (setq message (apply #'format-message message args)))
+    (when minibuffer-message-properties
+      (setq message (apply #'propertize message minibuffer-message-properties)))
     (let ((ol (make-overlay (point-max) (point-max) nil t t))
           ;; A quit during sit-for normally only interrupts the sit-for,
           ;; but since minibuffer-message is used at the end of a command,

bug#21112: 25; Patch: show minibuffer messages with a face

[Drew Adams]

> >> I'm not really convinced that there should be any face properties on the
> >> minibuffer messages at all, though.  :-)
> >
> > Yes, and a caller can always add whatever properties
> > it wants/needs.  It's not hard to pass a propertized
> > string to `minibuffer-message'.
> 
> It makes no sense for a caller of a particular command
> to decide whether to highlight the message or not.

Why would you decide that for everyone?  Can't you
imagine that it might make sense for some calling
code to do that?

Who said "command"?  Why shouldn't some code that calls
`minibuffer-message' propertize parts of that message
any way its author sees fit?  The caller can choose the
text to display; why shouldn't it be able to choose how
to emphasize (or whatever) particular parts of it?

> It should be user's preference whether to highlight
> all messages from all commands, or none at all.

All or nothing, eh?  Why so limited?

In any case, a user should also be able to choose
to use some library or other code that highlights
some text displayed by `minibuffer-message' in a
way deemed appropriate (by that code and that user).

User choices are not limited to user options and
faces.

A one-size-fits-all outlook is not Emacsy.  It
"makes no sense" for Emacs design to do that.

Emacs typically gives users (including coders)
enough rope to hang themselves on - on purpose,
because it tries to be flexible and maximize
their possibilities.

> If the user decided "I don't want caller's highlighting",
> a caller should not have the right to override user's preference.

If a user decides to use code that does the
kind of highlighting s?he wants, s?he should
be able to do that.

Customize is not the only knob users have, to
express choices.  Among the most common ways
to express choice are choosing to turn on
particular modes and load particular libraries.

> So we should not allow a caller to overwrite the default
> face properties, and I retract that part of my previous patch.

Whatever.

Many users are also code writers.  Most code
writers are also users.  Give users the
ability to adapt and adopt whatever they want
to, however they want to.

bug#21112: 25; Patch: show minibuffer messages with a face

[Juri Linkov]

>> This patch checks for existing face properties to not overwrite them:
>
> I'm not really convinced that there should be any face properties on the
> minibuffer messages at all, though.  :-)

Without highlighting of minibuffer messages there is a danger that the
message will remain unnoticed, especially in the multiline minibuffer.

So minibuffer messages need to be highlighted for the same reason
why the minibuffer prompt is already highlighted:

1. to designate non-editable read-only parts of the minibuffer;

2. to help the users to turn attention to the active part
   of the minibuffer.

Thus all informational text in the minibuffer should be highlighted
consistently in one color to help not to miss important message.

Isn't it so already that elsewhere in Emacs font-lock is used
to highlight more important parts of the buffer?

PS: I already added configurability in the previous patch,
so now we are discussing the default value.

bug#21112: 25; Patch: show minibuffer messages with a face

[Drew Adams]

> Without highlighting of minibuffer messages there is a danger that the
> message will remain unnoticed, especially in the multiline minibuffer.

Danger?  Really?

Some people don't like danger notices.
Some people don't like (what they call) "angry
fruit salad".  Some people don't like lots of
highlighting - or even any highlighting, e.g.
in something like Dired.  Some people even
turn off `font-lock-mode'.

(I'm not one of those people, but they exist.)

People are different.  Their use cases and
contexts of use are different.  One size does
not fit all.

> So minibuffer messages need to be highlighted for the same reason
> why the minibuffer prompt is already highlighted:


"Need to be"?  Neither of those things _needs_
to be highlighted.  Lots of us users will
appreciate that they can be highlighted.

We'll also appreciate being able to choose
how, how much, and whether they're highlighted.

> 1. to designate non-editable read-only parts of the minibuffer;
> 2. to help the users to turn attention to the active part
>    of the minibuffer.

I agree (personally and generally) with those
aids - helpful.  I don't agree about there
being "danger" if they are absent.

> Thus all informational text in the minibuffer should be highlighted
> consistently in one color to help not to miss important message.

"Thus"?  That doesn't follow, even if one accepts
your argument above.  Nothing in that argument
implies that ALL informational text in the
minibuffer should be highlighted CONSISTENTLY IN
ONE COLOR.

It's quite possible for important messages not to
be missed without such a paint-it-all-the-same
approach.  It's quite possible that some code
wants (and the users who choose to use that code
want) to emphasize certain parts of a message
specially - including precisely "to help not to
miss" something particularly noteworthy.

What is true in this regard of `message' is also
true of `minibuffer-message'.  Are you thinking
of imposing the same kind of blanket treatment
for `message'?  If not, why not?  Why doesn't
that apply also to `minibuffer-message'?

> Isn't it so already that elsewhere in Emacs font-lock is used
> to highlight more important parts of the buffer?

Font-lock does not impose a single face
("consistently in one color") for all its
highlighting, does it?  Why not?  Because it
can be useful to emphasize different things
differently...

bug#21112: 25; Patch: show minibuffer messages with a face

[Juri Linkov]

tags 21112 - wontfix
fixed 21112 27.0.50
thanks

> But this will overwrite the face properties the caller has set, right?

I pushed to master the patch that doesn't overwrite the face properties
the caller has set, and doesn't set face properties on all minibuffer messages
(nil by default).

bug#21112: 25; Patch: show minibuffer messages with a face

[Drew Adams]

> For consistency with isearch messages that are highlighted with the
> minibuffer-prompt face, minibuffer-message needs to do the same.

Neither Isearch prompts nor `minibuffer-message' output
should be highlighted with face `minibuffer-prompt'.

Isearch doesn't use the minibuffer.
And `minibuffer-message' is not a prompt.

> But since a message is displayed at different part of the minibuffer,
> it should be highlighted using a new separate customizable variable
> similar to minibuffer-prompt-properties:

1. If you go that route, which lets libraries and
users easily change the properties (good), please
separate Isearch and `minibuffer-message'.  Use two
different variables.  They are not the same species.

The default value could be, but it need not be,
the same for both.

On the other hand, it could be helpful to separate
out property `face', defining an actual face (for
each of Isearch and `minibuffer-message') that
users can customize for this.  That also has the
benefit that one can inherit from one to the other.

The other properties would be applied first, so that
if `face' is among them for some reason it will be
overridden by the face provided specifically for this.

2. The doc string of `minibuffer-message-properties'
should not say that the properties are added to
"minibuffer messages" - that's too broad.  It should
say that they are added to the text shown by function
`minibuffer-message' - or else describe that text,
and only that text, in another way.

The doc string of the similar variable for Isearch
should say that the properties are added to "the
search prompt" or some such.  Not sure whether the
right description is "prompt", but whatever is the
best way to describe it should be used in the doc
string.

bug#21112: 25; Patch: show minibuffer messages with a face

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

>> But since a message is displayed at different part of the minibuffer,
>> it should be highlighted using a new separate customizable variable
>> similar to minibuffer-prompt-properties:
>
> 1. If you go that route, which lets libraries and
> users easily change the properties (good), please
> separate Isearch and `minibuffer-message'.  Use two
> different variables.  They are not the same species.
>
> The default value could be, but it need not be,
> the same for both.

OK, implemented in the following patch.

> On the other hand, it could be helpful to separate
> out property `face', defining an actual face (for
> each of Isearch and `minibuffer-message') that
> users can customize for this.  That also has the
> benefit that one can inherit from one to the other.
>
> The other properties would be applied first, so that
> if `face' is among them for some reason it will be
> overridden by the face provided specifically for this.

There are already too many faces in M-x list-faces-display
for users to comprehend that adding three more faces with
the same color would make matters worse.

> 2. The doc string of `minibuffer-message-properties'
> should not say that the properties are added to
> "minibuffer messages" - that's too broad.  It should
> say that they are added to the text shown by function
> `minibuffer-message' - or else describe that text,
> and only that text, in another way.

OK, fixed in the attached patch.

> The doc string of the similar variable for Isearch
> should say that the properties are added to "the
> search prompt" or some such.  Not sure whether the
> right description is "prompt", but whatever is the
> best way to describe it should be used in the doc
> string.

OK, added to this patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: minibuffer-message-properties.2.patch --]
[-- Type: text/x-diff, Size: 2366 bytes --]

diff --git a/lisp/isearch.el b/lisp/isearch.el
index f150a3bba4..94c30eb57b 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -1992,13 +1992,17 @@ isearch-define-mode-toggle
   (setq isearch-regexp (not isearch-regexp))
   (if isearch-regexp (setq isearch-regexp-function nil)))
 
+(defvar isearch-message-properties minibuffer-prompt-properties
+  "Text properties that are added to the isearch prompt.")
+
 (defun isearch--momentary-message (string)
   "Print STRING at the end of the isearch prompt for 1 second"
   (let ((message-log-max nil))
     (message "%s%s%s"
              (isearch-message-prefix nil isearch-nonincremental)
              isearch-message
-             (propertize (format " [%s]" string) 'face 'minibuffer-prompt)))
+             (apply #'propertize (format " [%s]" string)
+                    isearch-message-properties)))
   (sit-for 1))
 
 (isearch-define-mode-toggle lax-whitespace " " nil
@@ -3202,18 +3206,18 @@ isearch-message-prefix
 			(concat " [" current-input-method-title "]: "))
 		     ": ")
 		   )))
-    (propertize (concat (isearch-lazy-count-format)
+    (apply #'propertize (concat (isearch-lazy-count-format)
                         (upcase (substring m 0 1)) (substring m 1))
-		'face 'minibuffer-prompt)))
+	   isearch-message-properties)))
 
 (defun isearch-message-suffix (&optional c-q-hack)
-  (propertize (concat (if c-q-hack "^Q" "")
+  (apply #'propertize (concat (if c-q-hack "^Q" "")
 		      (isearch-lazy-count-format 'suffix)
 		      (if isearch-error
 			  (concat " [" isearch-error "]")
 			"")
 		      (or isearch-message-suffix-add ""))
-	      'face 'minibuffer-prompt))
+	 isearch-message-properties))
 
 (defun isearch-lazy-count-format (&optional suffix-p)
   "Format the current match number and the total number of matches.
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 57702760fb..9a473b6867 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -693,6 +693,9 @@ minibuffer
   :link '(custom-manual "(emacs)Minibuffer")
   :group 'environment)
 
+(defvar minibuffer-message-properties minibuffer-prompt-properties
+  "Text properties added to the text shown by `minibuffer-message'.")
+
 (defun minibuffer-message (message &rest args)
   "Temporarily display MESSAGE at the end of the minibuffer.
 The text is displayed for `minibuffer-message-timeout' seconds,

bug#21112: 25; Patch: show minibuffer messages with a face

[Drew Adams]

> >> But since a message is displayed at different part of the minibuffer,
> >> it should be highlighted using a new separate customizable variable
> >> similar to minibuffer-prompt-properties:
> >
> > 1. If you go that route, which lets libraries and
> > users easily change the properties (good), please
> > separate Isearch and `minibuffer-message'.  Use two
> > different variables.  They are not the same species.
> >
> > The default value could be, but it need not be,
> > the same for both.
> 
> OK, implemented in the following patch.
> 
> > On the other hand, it could be helpful to separate
> > out property `face', defining an actual face (for
> > each of Isearch and `minibuffer-message') that
> > users can customize for this.  That also has the
> > benefit that one can inherit from one to the other.
> >
> > The other properties would be applied first, so that
> > if `face' is among them for some reason it will be
> > overridden by the face provided specifically for this.
> 
> There are already too many faces in M-x list-faces-display
> for users to comprehend that adding three more faces with
> the same color would make matters worse.

That's not a good argument for not adding faces.
Users and libraries can already create any
number of faces.

The solution for that problem, which is not
relevant here, is to give `list-faces-display'
a way to filter (e.g. on an input pattern).

Users deserve an easy way to have whatever
faces they want for such prompts/msgs, including
being able to inherit etc.  Let them, not you/us,
decide individually whether/when faces should
appear the same.

Easy to do.  No penalty.  But yes,
`list-faces-display', like `list-colors-display'
and some others, could benefit from incremental
filtering.

> > 2. The doc string of `minibuffer-message-properties'
> > should not say that the properties are added to
> > "minibuffer messages" - that's too broad.  It should
> > say that they are added to the text shown by function
> > `minibuffer-message' - or else describe that text,
> > and only that text, in another way.
> 
> OK, fixed in the attached patch.
> 
> > The doc string of the similar variable for Isearch
> > should say that the properties are added to "the
> > search prompt" or some such.  Not sure whether the
> > right description is "prompt", but whatever is the
> > best way to describe it should be used in the doc
> > string.
> 
> OK, added to this patch:

Haven't looked at the patch (no time now), but
I'm sure it's an improvement.  Thx.