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 06:52:31 -0700 (PDT) Message-ID: References: <<8736lmi2dg.fsf@gmail.com>> < <54cf21f3-86fa-4af4-9872-7493b44e2f6f@default>> <> <<83o949ecdc.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="170613"; mail-complaints-to="usenet@blaine.gmane.org" Cc: drew.adams@oracle.com, emacs-devel@gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 11 15:54:56 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 1hPSSl-000iFi-GU for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 15:54:55 +0200 Original-Received: from localhost ([127.0.0.1]:59099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPSSk-0005os-Ar for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 09:54:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPSSV-0005oj-9k for emacs-devel@gnu.org; Sat, 11 May 2019 09:54:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPSSU-0005Z6-5t for emacs-devel@gnu.org; Sat, 11 May 2019 09:54:39 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:36052) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPSSS-0005YE-F2; Sat, 11 May 2019 09:54:36 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4BDmIK2102107; Sat, 11 May 2019 13:54:35 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=cz69Ea/l6Ii3RYwJjK5K9RTAQpsj0OxTMrvY5WoJkh4=; b=Vu1Qk6UekGwffisuNzOYbk2E0fnw/KFMYVw6/F96MeZ6jRurXrUHVz6P8uJnCrEbN0Fz GM77vv3YokqYvvY6fb4Q8XBkMju5pNPYOGegVPV42qohtcH0mAEaZNE1N6XGa8o3tEtC hSdKFHfmNQfUI2iR02jXUL9Ft94MVMGt9oXwmkA5txy5OfkvwN43iPPedvUEEK7iyAbi GIvE2RaV7L508tS59iFnm8qxvgz4WzduQNWsvBVOhU1mBQy1fDfYeYWKdmU2DxAOp7Lm DbSoVPEp6p1HfVmlUMcPekW31bYjjQoE4hQ07EtvzD96aHMZZ2k8w//e9Kk3VJSk8DMH EQ== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2sdq1q0xxa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 11 May 2019 13:54:34 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4BDqWHp008181; Sat, 11 May 2019 13:52:34 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 2sdnqhckxb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 11 May 2019 13:52:34 +0000 Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x4BDqWsS029820; Sat, 11 May 2019 13:52:33 GMT In-Reply-To: <<83o949ecdc.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-1905110101 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-1905110101 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.85 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:236420 Archived-At: > > > 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. >=20 > 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. >=20 > 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.