GNU bug report logs - #35564
27.0.50; [PATCH] Tweak dired-do-shell-command warning about "wildcard" characters

Previous Next

Package: emacs;

Reported by: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>

Date: Sat, 4 May 2019 18:03:02 UTC

Severity: normal

Tags: fixed, moreinfo, patch

Merged with 28969

Found in version 27.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #148 received at 35564 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 35564 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, npostavs <at> gmail.com
Subject: Re: bug#35564: [PATCH v4] Tweak dired warning about "wildcard"
 characters
Date: Fri, 09 Aug 2019 21:03:49 +0300
>> 2. The current question is too ambiguous:
>>
>>   Confirm--do you mean to use ‘?’ as a wildcard? (y or n)
>>
>> A wildcard can mean both dired substitution and shell substitution.
>> A better question should use the same terms as documented in the
>> docstring of `dired-do-shell-command', i.e. "marked files", "file list".
>> So a better question would be:
>>
>>   Confirm--do you mean to substitute ‘?’ with marked files? (y or n)
>>
>> Or something similar that makes clear that substitution applies
>> to dired files, not files matched by shell.
>
> Mmm, I think that the current prompt *does* use the same terms as
> documented in the docstring: it simply mistakenly assumes that if '?'
> and '*' are not "isolated", the shell will unconditionally process them
> as wildcards.  It is a heuristic that fails to consider that '?' and '*'
> may be quoted or escaped.

Do you mean this case: despite that the docstring of
`dired-do-shell-command' mentions "a shell wildcard",
typing on a file:

  ! cat '*'

and confirming with `y':

  Confirm--do you mean to use ‘*’ as a wildcard? (y or n) y

still doesn't use * as "a shell wildcard".  Then I agree.

>> As was already discussed in this thread, using (:inherit '(warning underline))
>> will solve this problem and improve accessibility.  So there will be
>> no need in multi-line prompt when using underline face attribute.
>
> Mmm.  I went to a TTY to check how (:inherit '(underline)) looks.  Since
> (display-supports-face-attributes-p '(:underline t)) is nil there, the
> "underline" face is defined as (:weight bold), which merely makes the
> foreground color brighter.  So (:inherit '(warning underline)) amounts
> to just (:inherit '(warning)).
>
> Perhaps (display-supports-face-attributes-p '(:underline t)) can be used
> to decide whether we need to add ^ markers.

You can check all possible face attributes to find the one
available on tty: underline, weight: bold, inverse-video, ...




This bug report was last modified 4 years and 296 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.