unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: RE: Use of minibuffer-prompt face when minibuffer is not involved
Date: Sat, 11 May 2019 07:34:25 -0700 (PDT)	[thread overview]
Message-ID: <6fca137b-3e28-45b4-807b-9334e87812f9@default> (raw)
In-Reply-To: <<83o949cc88.fsf@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.

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.



  parent reply	other threads:[~2019-05-11 14:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 18:35 Use of minibuffer-prompt face when minibuffer is not involved Kévin Le Gouguec
2019-05-10 20:52 ` Stefan Monnier
2019-05-10 21:59   ` Drew Adams
2019-05-10 22:36     ` Stefan Monnier
2019-05-11  6:25       ` Eli Zaretskii
2019-05-11 13:22     ` Kévin Le Gouguec
     [not found]     ` <<jwvftpm9buh.fsf-monnier+emacs@gnu.org>
     [not found]       ` <<83o949ecdc.fsf@gnu.org>
2019-05-11 13:52         ` Drew Adams
2019-05-11 14:11           ` Eli Zaretskii
2019-05-12 22:31             ` Richard Stallman
2019-05-12 23:32               ` Drew Adams
     [not found]     ` <<<jwvftpm9buh.fsf-monnier+emacs@gnu.org>
     [not found]       ` <<<83o949ecdc.fsf@gnu.org>
     [not found]         ` <<c7e501bb-9dd8-4b00-8647-d0731f2b2565@default>
     [not found]           ` <<83o949cc88.fsf@gnu.org>
2019-05-11 14:34             ` Drew Adams [this message]
2019-05-11 13:50   ` Solving bug#35564 (was: Use of minibuffer-prompt face when minibuffer is not involved) Kévin Le Gouguec
2019-05-11 14:13     ` Solving bug#35564 Stefan Monnier
     [not found] <<<8736lmi2dg.fsf@gmail.com>
     [not found] <<8736lmi2dg.fsf@gmail.com>

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=6fca137b-3e28-45b4-807b-9334e87812f9@default \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).