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.