From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Use of minibuffer-prompt face when minibuffer is not involved Date: Sat, 11 May 2019 07:34:25 -0700 (PDT) Message-ID: <6fca137b-3e28-45b4-807b-9334e87812f9@default> References: <<<8736lmi2dg.fsf@gmail.com>>> << <54cf21f3-86fa-4af4-9872-7493b44e2f6f@default>>> <<>> <<<83o949ecdc.fsf@gnu.org>>> <> <<83o949cc88.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88882"; mail-complaints-to="usenet@blaine.gmane.org" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 11 16:36:42 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hPT7C-000N1a-0c for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 16:36:42 +0200 Original-Received: from localhost ([127.0.0.1]:59782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPT7A-0006GK-QB for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 10:36:40 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPT73-0006Fy-Uv for emacs-devel@gnu.org; Sat, 11 May 2019 10:36:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPT72-0003HQ-U1 for emacs-devel@gnu.org; Sat, 11 May 2019 10:36:33 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:35314) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPT71-0003GG-Az; Sat, 11 May 2019 10:36:31 -0400 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4BEY3be125512; Sat, 11 May 2019 14:36:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=b0GdZo9SY8SnSHxjGooDIbRO0NETikTmL/OzOEqMirs=; b=Vz+tzIYsIIAudhpvCA0ZnGT84d3a/TO61kcoKxGtOz7tNhrWXHRjenTsPjWKNgFEZsgp XNfr9mShW95DvRecohQB2dp4kUGeDXKQ36+q91DwBPukKXWH83DR/84k4tvCsay5/1lB mtEr1n/IcaSYhlMSRfUsdWeO3Lc2WwXxLdIMYHFavsV3RbpWgHcYH9gMblKDoC3rXi7R vE/c6FOQ6BQpNkS/sxX19jKqwP+vo5DGpC+pl6cgxHGz3IjojH6EwgH5Er79obcemJmM RtT/jcp2007ZKCN/Tx0sqYrSz+WrHDTA3uoVaTcFSpOzlMR5Qu/e1KjWwEh5CYaUej+8 2w== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2130.oracle.com with ESMTP id 2sdkwd99xb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 11 May 2019 14:36:29 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4BEXNYM100386; Sat, 11 May 2019 14:34:28 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2sdme9wjtd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 11 May 2019 14:34:28 +0000 Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x4BEYQLb020447; Sat, 11 May 2019 14:34:27 GMT In-Reply-To: <<83o949cc88.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4849.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9253 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905110106 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9253 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905110106 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.79 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236430 Archived-At: > > > 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". >=20 > 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.) >=20 > 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. >=20 > 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? >=20 > 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.