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: Fri, 10 May 2019 14:59:44 -0700 (PDT) Message-ID: <54cf21f3-86fa-4af4-9872-7493b44e2f6f@default> References: <8736lmi2dg.fsf@gmail.com> 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="140632"; mail-complaints-to="usenet@blaine.gmane.org" To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 11 00:00:28 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 1hPDZ4-000aQc-WA for ged-emacs-devel@m.gmane.org; Sat, 11 May 2019 00:00:27 +0200 Original-Received: from localhost ([127.0.0.1]:50608 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPDZ3-0005iN-WE for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 18:00:26 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPDYV-0005iG-Ft for emacs-devel@gnu.org; Fri, 10 May 2019 17:59:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPDYU-0004kE-6d for emacs-devel@gnu.org; Fri, 10 May 2019 17:59:51 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:50784) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPDYT-0004j5-UO for emacs-devel@gnu.org; Fri, 10 May 2019 17:59:50 -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 x4ALsp4F122448; Fri, 10 May 2019 21:59:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=RNLit+J2ZgYjYcyrf1Ciq37seHFIWmFE6d46vVFIT+s=; b=dpEcLIA+lraiqJNgkRaaclu4PRmJPD99OQdoDy5ZbJSMlS1M0eM9trX7+HuU1+5o5oRM qsTHuWNdkjyKLLLtP3qMZh3ToRREQSayfB+x6VSPNkr1e0R+pHhBtBp8h82sqwKAZC94 VeLWN2Q7zE3jyKCCpe5+TZXiYVEUdNfKX62dtePJCC0Wzrty7spYoFEp10uAXWtuLtJC XFjKVuUQYdGvO6mEmfuexCrUEwzeF42AmwClkQ8Jt8vruAiSJIxffy30701qPCFq5SIt Zx24+qfaiv2BgaBlQdhutEFA73LY3T2ed8cpC4jPnJFAV4S3da6DP8Fvy89Cd6Riv4kj 2Q== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 2s94b1bptw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 May 2019 21:59:46 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4ALwWWb131763; Fri, 10 May 2019 21:59:46 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2sagyw2eew-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 May 2019 21:59:46 +0000 Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x4ALxjQs005786; Fri, 10 May 2019 21:59:45 GMT In-Reply-To: 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-1905100138 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-1905100138 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:236397 Archived-At: > > 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.") >=20 > That's what I vote for. >=20 > 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. >=20 > 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.