From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#35564: 27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters Date: Tue, 7 May 2019 10:15:42 +0200 Message-ID: <9bd289fe-3623-4c45-4c4f-04c6668cae76@gmx.at> References: <87zho2cd4f.fsf@gmail.com> <071cc96c-1bf2-f331-8f9e-b3c54a7452da@gmx.at> <877eb3e5im.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="143005"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35564@debbugs.gnu.org To: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 07 10:16:23 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1hNvGx-000b62-9V for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 May 2019 10:16:23 +0200 Original-Received: from localhost ([127.0.0.1]:41991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNvGw-00005b-AR for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 May 2019 04:16:22 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNvGd-0008TP-Ek for bug-gnu-emacs@gnu.org; Tue, 07 May 2019 04:16:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNvGc-0006PB-HJ for bug-gnu-emacs@gnu.org; Tue, 07 May 2019 04:16:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44622) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hNvGc-0006P5-Dv for bug-gnu-emacs@gnu.org; Tue, 07 May 2019 04:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hNvGc-0001S2-6M for bug-gnu-emacs@gnu.org; Tue, 07 May 2019 04:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 May 2019 08:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35564 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35564-submit@debbugs.gnu.org id=B35564.15572169485548 (code B ref 35564); Tue, 07 May 2019 08:16:02 +0000 Original-Received: (at 35564) by debbugs.gnu.org; 7 May 2019 08:15:48 +0000 Original-Received: from localhost ([127.0.0.1]:58163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hNvGN-0001RQ-TB for submit@debbugs.gnu.org; Tue, 07 May 2019 04:15:48 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:59211) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hNvGM-0001RC-AK for 35564@debbugs.gnu.org; Tue, 07 May 2019 04:15:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557216940; bh=M+Ew0w+/jLPccHQv9GmiVTcO2wRWmoPZZ0BdchD2rho=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ThW6D5AZDehdNlPxv7XQ+9CzOF2J/QZUln2Yh5sDuL8xDHApPV4nmHERyAEmn40pn OiZ4FqS+Fg5lc9DivDvQnECjAKY9hozX1qRZUJJUilUeZZ+H2nFfB7BKUgMXc3DHcS PVrDKXxbWA6y3pGw9T79sHXPiTjetHM70lQV3Aug= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.94]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MJGFi-1hQf573g66-002lN9; Tue, 07 May 2019 10:15:39 +0200 In-Reply-To: <877eb3e5im.fsf@gmail.com> Content-Language: de-DE X-Provags-ID: V03:K1:UunCkSMnvbAPI9igSPMOeA3O7xsJ58px7hjZYtkBTjQX+ISnDLL jwF6UQz2s74rCg0bkqtAsvmbYfPYiOCRR7D1Ve/jFppJS+s5uXJy65CQTLAEuYXSFt77XkU X/6/SO2tPpC2O4FclSYkyAUmEsBHAQPZmMsUWOOeWJGISH2AVoi7tcXUu3caWkqZ7Uq+edp 1P/KpSwvcKI3PTJdnm8mw== X-UI-Out-Filterresults: notjunk:1;V03:K0:LkDQuh2HP9I=:nUO4oWXRzPjLE13rt8qkSd 0qK9wCix9WmvjoHrvfDG2/dH/BHu6WtygJlJkPLmjNTAtPRjhAzMMGdMZSgN+5NIjOZnGhIDG Rm24dV1RVJW2Tt5ancdHuZqYMttDHxE4kjqx8ADF/bkwTVJ3BFnMFaeS7E4YpcRwYc9N6PS6C S0+HesCumn8n3A7qgoy1VaC3xiEfcsc91fQHsBY/gDLlrBAusoJsYq5yCceDk3OsMfhIh7I04 M3w8O5RxFDAQpf5eDy8JwhJ1xnswH5YWNFAw1rLX5jsyOYoOl2ExHEpARsJ4uDPKrEmJuWT24 PGHPYS3wF5OSlOWMlFKdlC5GWi/O3nZOuKoPjwJktrWnMkJurdXW8nCoQae9Sx6xHy9TreWZZ M6AHJAsBnEQqDxoC7Jnw57o95PDl4tZSgk2OdOUBX3APSz2nQpi6qDMwYDFQqcWOZD7vA0SJk BJpn09wdj0V5ogq11GzfiRf7VdDpt5UF+Fif8A4e0HWt4Lk3GeRHIXBALHIEh2st58nt2wmhj CYMCmwz0Dzj8cFts5+so8cK2NKRDcontSHyfyRzQCJA+VrsdKMza9PxKNCNKe9koH9JGvp/eJ hJGEWDgdDqgaJziL7zYwJtaW7evUmQrb21rUJQJech1VMVPj3nImgPR1p4A71WPh1VORlBEr6 lCTDRfR+jA4+IH7PixyvCWIIbW84P5QdDKIyeeapiMT+3nbr3CIZvn3cBrJ5wCcMEvNaj9ZGf 7t4xz8h37INoVFdlti6opP3c0SH3qiP44YZR2x8dwNja7VvByznqGZ6/Chj9Dkh85h0J3i9l X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158862 Archived-At: > I dug into yes-or-no-p until I came across `read_minibuf()'; is this the > code you are referring to? It is. > If one were to fix the issue of y-or-n-p hardcoding the face property, > what would be the best way to go? > > 1. Make a C DEFUN out of this snippet, and have it called by > `read_minibuf()' and `y-or-n-p'. > > 2. Re-implement this snippet as an Elisp defun, and have it called by > `read_minibuf()' and `y-or-n-p'. > > 3. (Re-implement this snippet within `y-or-n-p'.) > > (FWIW, the attached patch seems to work as a workaround, but I assume > solutions 1 or 2 would be better, by virtue of reusing code) By design, 'yes-or-no-p' and 'y-or-n-p' are kept apart to avoid that people use the latter for more "crucial decisions". Part of this distinction is that 'y-or-n-p' is asked in the echo area, so applying 'minibuffer-prompt-properties' would be conceptually inappropriate. Obviously, applying 'minibuffer-prompt' is just as inappropriate (that face is part of 'minibuffer-prompt-properties') but that's a decision that has been made long ago. So although I'd vote for a solution like the one you propose in your patch, any decision in this area is subtle and should be approved by others first. Also because we'd then have to decide what to do with other clients of the 'minibuffer-prompt' face like 'read-char-choice' or the ones in isearch.el. martin