Use of minibuffer-prompt face when minibuffer is not involved

Use of minibuffer-prompt face when minibuffer is not involved

[Kévin Le Gouguec]

Hello Emacs,

For some reason[1], I found myself wanting to add text properties to
y-or-n-p's prompt.  This is currently not possible, as the prompt's
face property is hard-coded like so:

    (propertize (if (memq answer scroll-actions)
                    prompt
                  (concat "Please answer y or n.  "
                          prompt))
                'face 'minibuffer-prompt)))))

An ad-hoc fix seems simple enough[2]; further discussion with Martin
Rudalics and Drew Adams showed that:

- there are other places where this (propertize … 'face
  'minibuffer-prompt) idiom is used, such as isearch prompts and
  read-char-choice;

- these examples do not actually activate the minibuffer (AFAIU), so
  using the minibuffer-prompt face could be considered questionable.

Considering all that, what course of action do you consider worth
pursuing?

0. Do nothing. ("The face might be called minibuffer-prompt, but there
   are enough non-minibuffer uses of it that it's not worth fixing
   this inconsistency at this point.")

1. Introduce a new face named e.g. prompt, which by default would…

   1. … inherit minibuffer-prompt for "visual backward-compatibility".

   2. … differ from minibuffer-prompt to teach users the distinction
      between echo area and minibuffer.

2. Stop propertizing the prompt; no new face.

I have no horse in this race[3]; I understand both the appeal of 0
(minimize churn and UI inconsistencies during the transition), 1.1
(configurability and smooth transition), 1.2 and 2 (consistency and
pedagogy).

WDYT?


NB: the discussion on bug#35564 also touched on text properties with
tooltips; I figured the subject of (message …)'d prompts is
substantial enough that tooltips could be discussed separately, but
please make sure to check out Martin and Drew's thoughts on the matter
if this is something you want to discuss.


[1] To sum up my initial report over at bug#35564:

    - dired-do-shell-command's warning about "wildcard" characters
      annoys me, since AFAICT they may not be wildcards at all
      (e.g. they may be quoted or backslash-escaped).

    - Rather than coming up with a better warning, I toyed with text
      properties to build a prompt which highlights these characters.

    - I found out that y-or-n-p discards my prompt's text properties.

[2] See patch at bug#35564#11.

[3] Mainly I'd like to fix bug#35564.  I assume it can be fixed
    whichever way this discussion goes:

    1. either someone finds a better phrasing for Dired's warning,

    2. or the highlighted prompt implemented in bug#35564#5 is deemed
       cute enough and we decide to change y-or-n-p's (propertize …)
       into (add-face-text-property …)

       1. either locally in y-or-n-p,

       2. or in a new function which could be re-used by
          read-char-choice et al.,
          
    3. or someone enlightens me as to why Dired calling these
       characters "wildcards" is TRT, making the bug report moot.

Re: Use of minibuffer-prompt face when minibuffer is not involved

[Stefan Monnier]

> 0. Do nothing. ("The face might be called minibuffer-prompt, but there
>    are enough non-minibuffer uses of it that it's not worth fixing
>    this inconsistency at this point.")

That's what I vote for.

More to the point, I think the difference between minibuffer prompts and
non-minibuffer prompts should be a purely internal one.  After all, you
could rewrite yes-or-no-p so as not to use a minibuffer or rewrite
y-or-n-p to make it use a minibuffer: should that have as a side-effect
to use a different face, really?

>     - dired-do-shell-command's warning about "wildcard" characters
>       annoys me, since AFAICT they may not be wildcards at all
>       (e.g. they may be quoted or backslash-escaped).
>
>     - Rather than coming up with a better warning, I toyed with text
>       properties to build a prompt which highlights these characters.
>
>     - I found out that y-or-n-p discards my prompt's text properties.

So the problem is not the use of minibuffer-prompt but the fact that it
overrides other faces while applying it.  That should be easy to fix by
using `add-face-text-property` instead of `propertize`.


        Stefan

RE: Use of minibuffer-prompt face when minibuffer is not involved

[Drew Adams]

> > 0. Do nothing. ("The face might be called minibuffer-prompt, but there
> >    are enough non-minibuffer uses of it that it's not worth fixing
> >    this inconsistency at this point.")
> 
> That's what I vote for.
> 
> More to the point, I think the difference between minibuffer prompts and
> non-minibuffer prompts should be a purely internal one.  After all, you
> could rewrite yes-or-no-p so as not to use a minibuffer or rewrite
> y-or-n-p to make it use a minibuffer: should that have as a side-effect
> to use a different face, really?

It's not about y-or-n-p or yes-or-no-p.  That's the
wrong way to look at it.  Yes-or-no-p is not at all
representative of minibuffer prompting for input.

`minibuffer-prompt' face should be a clear indicator
to users that the minibuffer is active.

Prompting for non-minibuffer input should either not
have a face or should use a different face.

(Users can of course themselves define that face to
look the same as `minibuffer-prompt' if they really
want such "consistency", but Emacs itself should not
force-confuse/identify the two.)

> >     - dired-do-shell-command's warning about "wildcard" characters
> >       annoys me, since AFAICT they may not be wildcards at all
> >       (e.g. they may be quoted or backslash-escaped).
> >
> >     - Rather than coming up with a better warning, I toyed with text
> >       properties to build a prompt which highlights these characters.
> >
> >     - I found out that y-or-n-p discards my prompt's text properties.
> 
> So the problem is not the use of minibuffer-prompt but the fact that it
> overrides other faces while applying it.  That should be easy to fix by
> using `add-face-text-property` instead of `propertize`.

No.  That is not "the problem".  That is something
altogether different.

The "problem" reported for `dired-do-shell-command'
has _nothing_ to do with the question of whether
non-minibuffer prompting should use a face and, if
so, which face.

This emacs-dev thread should _drop_ the question of
`dired-do-shell-command' and whether or how its
prompting should best be worded or highlighted or
whatever.

It was a _mistake_ for the bug thread to ever have
confounded the two discussions - and even to confound
a third, also unrelated. discussion about allowing
text properties for `help-echo' tooltips.

The question raised for emacs-devel by this thread
is whether non-minbuffer prompting should have a
face, and if so, which face.

Re: Use of minibuffer-prompt face when minibuffer is not involved

[Stefan Monnier]

> The question raised for emacs-devel by this thread
> is whether non-minbuffer prompting should have a
> face, and if so, which face.

My answer was to this question.  Let me repeat it to make it clear:
the difference between minibuffer prompts and
non-minibuffer prompts should be a purely internal one.


        Stefan

Re: Use of minibuffer-prompt face when minibuffer is not involved

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 10 May 2019 18:36:28 -0400
> Cc: emacs-devel@gnu.org
> 
> > The question raised for emacs-devel by this thread
> > is whether non-minbuffer prompting should have a
> > face, and if so, which face.
> 
> My answer was to this question.  Let me repeat it to make it clear:
> the difference between minibuffer prompts and
> non-minibuffer prompts should be a purely internal one.

And I agree 100%.  I think it's a grave mistake to try to tell the
user via faces whether some prompt/text is in the active minibuffer or
not.  That just confuses the user with no real gain.

Active minibuffer is an internal detail.  I wish it didn't exist at
all, but our implementation forces us to have it.  Exposing that to
users is exactly the wrong idea.

Re: Use of minibuffer-prompt face when minibuffer is not involved

[Kévin Le Gouguec]

Drew Adams <drew.adams@oracle.com> writes:

> This emacs-dev thread should _drop_ the question of
> `dired-do-shell-command' and whether or how its
> prompting should best be worded or highlighted or
> whatever.
>
> It was a _mistake_ for the bug thread to ever have
> confounded the two discussions - and even to confound
> a third, also unrelated. discussion about allowing
> text properties for `help-echo' tooltips.
>
> The question raised for emacs-devel by this thread
> is whether non-minbuffer prompting should have a
> face, and if so, which face.

Right.  Apologies for mentioning the bug thread on emacs-devel.  I hoped
that confining it too footnotes would ensure that it would not derail
this thread (while avoiding the XY problem of not mentioning *why* I was
looking at these prompts in the first place); obviously I misjudged.

Solving bug#35564 (was: Use of minibuffer-prompt face when minibuffer is not involved)

[Kévin Le Gouguec]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So the problem is not the use of minibuffer-prompt but the fact that it
> overrides other faces while applying it.  That should be easy to fix by
> using `add-face-text-property` instead of `propertize`.

Yep, which is what the patch over at bug#35564#11 does.  Now it's mostly
a matter of deciding whether we want to solve this bug this way (IMO:
not if someone can simply come up with a better warning and do away with
my highlighted-prompt shenanigans).

If we do, I'll add a proper patch series to this report, to

1. fix y-or-n-p with add-face-text-property,
2. tweak dired's warning using text properties.

RE: Use of minibuffer-prompt face when minibuffer is not involved

[Drew Adams]

> > > The question raised for emacs-devel by this thread
> > > is whether non-minbuffer prompting should have a
> > > face, and if so, which face.
> >
> > My answer was to this question.  Let me repeat it to make it clear:
> > the difference between minibuffer prompts and
> > non-minibuffer prompts should be a purely internal one.
> 
> And I agree 100%.  I think it's a grave mistake to try to tell the
> user via faces whether some prompt/text is in the active minibuffer or
> not.  That just confuses the user with no real gain.
> 
> Active minibuffer is an internal detail.  I wish it didn't exist at
> all, but our implementation forces us to have it.  Exposing that to
> users is exactly the wrong idea.

Active minibuffer is in _no_ way "an internal detail".

It's about users knowing that the minibuffer is available
for editing.

And it's about users knowing that the minibuffer is then
the _only_ place/way to input their response.  If it has
lost focus (e.g. by clicking another frame or by other
interactions with Emacs) then they need to refocus it to
reply to the minibuffer prompt.

There is a world of difference - user-observable - between
`read-char' (e.g. `y-or-n-p'), which takes no account of
focus, and reading input from the minibuffer.  And yet the
difference is sometimes not obvious to users.  Yes, a big
difference but not necessarily obvious.

In fact, it would be better in general if we made it
more obvious when the minibuffer is active (as opposed
to the same space being used as the echo area).

With my standalone minibuffer (separate frame) I do that
by shading the frame background differently.  And I do
the same thing (but with a different shade) to indicate
that Isearch is active in that same area.

"Grave mistake"?  Why do you say so?  (No reason given.)

We (since Emacs 22, at least) now provide two different
faces for the mode-line, to show which window is active
(selected) - which has the focus.  This is very similar:
the minibuffer is a buffer in a window.  Users should
clearly see when it is focused for input ("active").

More generally still, when it comes to faces and text
properties, users deserve control - that's not something
to be imposed "internally".

No argument has been given yet supporting _why_ this
should be considered "internal".  Just two opinions
strongly proclaiming that it _is_ an internal detail.
Why do you think so?

The behavior difference is user-observable.  It should
be easily user-controllable.

Re: Use of minibuffer-prompt face when minibuffer is not involved

[Eli Zaretskii]

> Date: Sat, 11 May 2019 06:52:31 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: drew.adams@oracle.com, emacs-devel@gnu.org
> 
> > Active minibuffer is an internal detail.  I wish it didn't exist at
> > all, but our implementation forces us to have it.  Exposing that to
> > users is exactly the wrong idea.
> 
> Active minibuffer is in _no_ way "an internal detail".

You have 2 core Emacs developers disagree with you, which is a clear
sign that you are wrong.

> "Grave mistake"?  Why do you say so?  (No reason given.)

I actually did give a reason, please re-read what I wrote.

> We (since Emacs 22, at least) now provide two different
> faces for the mode-line, to show which window is active
> (selected) - which has the focus.  This is very similar:
> the minibuffer is a buffer in a window.

No, selected window is an entirely different concept.

> No argument has been given yet supporting _why_ this
> should be considered "internal".  Just two opinions
> strongly proclaiming that it _is_ an internal detail.
> Why do you think so?

Read the code, and you will clearly see that.

Re: Solving bug#35564

[Stefan Monnier]

> 1. fix y-or-n-p with add-face-text-property,

I think this is a good change, regardless of what happens w.r.t dired
and which face to use for this prompt.


        Stefan

RE: Use of minibuffer-prompt face when minibuffer is not involved

[Drew Adams]

> > > Active minibuffer is an internal detail.  I wish it didn't exist at
> > > all, but our implementation forces us to have it.  Exposing that to
> > > users is exactly the wrong idea.
> >
> > Active minibuffer is in _no_ way "an internal detail".
> 
> You have 2 core Emacs developers disagree with you, which is a clear
> sign that you are wrong.

I see no reasons given.  Argument from authority, with
no reasons given, only goes so far.  Neither core
developer has infallible judgment.

> > "Grave mistake"?  Why do you say so?  (No reason given.)
> 
> I actually did give a reason, please re-read what I wrote.

I still see no reason given.  Care to point it out?

> > We (since Emacs 22, at least) now provide two different
> > faces for the mode-line, to show which window is active
> > (selected) - which has the focus.  This is very similar:
> > the minibuffer is a buffer in a window.
> 
> No, selected window is an entirely different concept.

Everything that is not identical is different.  It is
very similar.  The minibuffer window and its frame are
selected, and they obtain the focus.  Minibuffer input
is input in a particular buffer and window.

> > No argument has been given yet supporting _why_ this
> > should be considered "internal".  Just two opinions
> > strongly proclaiming that it _is_ an internal detail.
> > Why do you think so?
> 
> Read the code, and you will clearly see that.

What code?  Why the enigmatic responses?  Can you not
please just state your reasons plainly?

Or are you saying that the implementation prohibits
_not_ using a face for `y-or-n-p', `read-char' and the
like, which do not use the minibuffer?

Or are you saying that the implementation prohibits
using a _different_ face from `minibuffer-prompt' for
that?

Either of those approaches, if not unfeasible for
implementation reasons, would be preferable to not
distinguishing (especially only doing so sometimes)
minibuffer prompting from other prompting.

What do you have against removing `minbuffer-prompt'
face from prompts that have nothing to do with
minibuffer input?

Are you saying that we _cannot_ separate appearance
of minibuffer prompt from other prompts because of
the implementation?  Or are you saying that we
_should_ not do that because it is no concern of
users and only Emacs developers should decide the
behavior once and for all?

Please clarify/elaborate.

Re: Use of minibuffer-prompt face when minibuffer is not involved

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Active minibuffer is in _no_ way "an internal detail".

  > You have 2 core Emacs developers disagree with you, which is a clear
  > sign that you are wrong.

That question is a matter of judgment, not objective fact.

If this were a question of objective fact, the maintainers could
conceivably be objectively wrong, and someoe else objectively right.
Such things are unusual, but they do happen.

But there is no objectively right in a question like this.  The
maintainers have to go by _their_ best judgment.  Others who disagree
can try to show good reasons for judging things differently; but if
the managers have understood those reasons and are not convinced by
them, that's the end of it.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: Use of minibuffer-prompt face when minibuffer is not involved

[Drew Adams]

>   > > Active minibuffer is in _no_ way "an internal detail".
> 
>   > You have 2 core Emacs developers disagree with you, which 
>   > is a clear sign that you are wrong.
> 
> That question is a matter of judgment, not objective fact.

It's an objective fact that the minibuffer being used for
input is observably different behavior from reading input
in other ways (e.g. `read-char').

If users can perceive different behavior then the
difference is not just an internal detail.  I don't think
that's a matter of judgment or opinion.

There may be implementation matters to consider, but that
doesn't change the fact that the behaviors are different
for _users_.

And anyway, no particular implementation matters were
presented for discussion.  There was only an invitation
to "see the code" (which?).
 
> If this were a question of objective fact, the maintainers could
> conceivably be objectively wrong, and someoe else objectively right.
> Such things are unusual, but they do happen.

What is "this"?  The question posed was whether
non-minbuffer prompts should have a face, and if so,
which face.  Everyone has so far agreed on that.

And yes, _that's_ a question of opinion/judgment.
Normally when such questions are raised here reasons
are given to support opinions, and ultimately the
maintainers decide/judge.

> But there is no objectively right in a question like this.  The
> maintainers have to go by _their_ best judgment.  Others who disagree
> can try to show good reasons for judging things differently; but if
> the managers have understood those reasons and are not convinced by
> them, that's the end of it.

Of course.  IF there has been a maintainer decision
that's one thing - that's the end of it.  So far, I
haven't understood that.

I've seen only expressions of opinion or preference.
I thought the question was open for discussion, which
to me invites reason, not just like/dislike votes.

One user opened the question for discussion; I replied
with one point of view and supporting arguments; then
two maintainers replied with like/dislike opinions
without reasons (AFAICT): "That's what I vote for."

If that's really the extent of the discussion, so be it.