bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#21112: 25; Patch: show minibuffer messages with a face
Date: Thu, 27 Jun 2019 14:19:45 -0700 (PDT)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]