[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Use of minibuffer-prompt face when minibuffer is not involved
From: |
Drew Adams |
Subject: |
RE: Use of minibuffer-prompt face when minibuffer is not involved |
Date: |
Sat, 11 May 2019 07:34:25 -0700 (PDT) |
> > > 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.
- Use of minibuffer-prompt face when minibuffer is not involved, Kévin Le Gouguec, 2019/05/10
- Re: Use of minibuffer-prompt face when minibuffer is not involved, Stefan Monnier, 2019/05/10
- RE: Use of minibuffer-prompt face when minibuffer is not involved, Drew Adams, 2019/05/10
- Re: Use of minibuffer-prompt face when minibuffer is not involved, Stefan Monnier, 2019/05/10
- Re: Use of minibuffer-prompt face when minibuffer is not involved, Eli Zaretskii, 2019/05/11
- RE: Use of minibuffer-prompt face when minibuffer is not involved, Drew Adams, 2019/05/11
- Re: Use of minibuffer-prompt face when minibuffer is not involved, Eli Zaretskii, 2019/05/11
- RE: Use of minibuffer-prompt face when minibuffer is not involved,
Drew Adams <=
- Re: Use of minibuffer-prompt face when minibuffer is not involved, Richard Stallman, 2019/05/12
- RE: Use of minibuffer-prompt face when minibuffer is not involved, Drew Adams, 2019/05/12
- Re: Use of minibuffer-prompt face when minibuffer is not involved, Kévin Le Gouguec, 2019/05/11
Solving bug#35564 (was: Use of minibuffer-prompt face when minibuffer is not involved), Kévin Le Gouguec, 2019/05/11