unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
	Raffaele Ricciardi <rfflrccrd@gmail.com>,
	21112@debbugs.gnu.org
Subject: bug#21112: 25; Patch: show minibuffer messages with a face
Date: Thu, 27 Jun 2019 14:19:45 -0700 (PDT)	[thread overview]
Message-ID: <884006f4-2f66-42c5-9737-4038a72c0d4a@default> (raw)
In-Reply-To: <87y31n9btf.fsf@mail.linkov.net>

> >> 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	other threads:[~2019-06-27 21:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 12:46 bug#21112: 25; Patch: show minibuffer messages with a face Raffaele Ricciardi
2015-07-22 13:42 ` Drew Adams
2015-07-22 13:44   ` Drew Adams
2015-07-22 15:27     ` Raffaele Ricciardi
2015-07-22 15:42       ` Drew Adams
2016-02-23  9:34 ` Lars Ingebrigtsen
2019-06-25 15:50   ` Lars Ingebrigtsen
2019-06-25 19:47     ` Juri Linkov
2019-06-25 20:43       ` Lars Ingebrigtsen
2019-06-26 21:28         ` Juri Linkov
2019-06-27 10:28           ` Lars Ingebrigtsen
2019-06-27 14:22             ` Drew Adams
2019-06-27 20:29               ` Juri Linkov
2019-06-27 21:19                 ` Drew Adams [this message]
2019-06-27 20:28             ` Juri Linkov
2019-06-27 21:37               ` Drew Adams
2019-07-04 22:01         ` Juri Linkov
2019-06-25 20:54       ` Drew Adams
2019-06-26 21:30         ` Juri Linkov
2019-06-26 22:13           ` Drew Adams

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=884006f4-2f66-42c5-9737-4038a72c0d4a@default \
    --to=drew.adams@oracle.com \
    --cc=21112@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --cc=larsi@gnus.org \
    --cc=rfflrccrd@gmail.com \
    /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).