From: Eli Zaretskii <eliz@gnu.org>
To: Allen Li <vianchielfaura@gmail.com>
Cc: 28615@debbugs.gnu.org
Subject: bug#28615: [PATCH] Clarify what grep-read-files wants
Date: Tue, 10 Oct 2017 10:52:01 +0300 [thread overview]
Message-ID: <83bmlfqw2m.fsf@gnu.org> (raw)
In-Reply-To: <CAJr1M6cqoVvp0_GQvyyaA4pvHYKZ41W2vdQ2wx5R3_Yt9YSrvg@mail.gmail.com> (message from Allen Li on Mon, 9 Oct 2017 23:51:47 -0700)
> From: Allen Li <vianchielfaura@gmail.com>
> Date: Mon, 9 Oct 2017 23:51:47 -0700
> Cc: 28615@debbugs.gnu.org
>
> Are you saying that a user might mistake the completion on
> grep-files-aliases as completion on file name?
Something like that, yes. In general, I don't think completing on
wildcards is useful.
> I believe that with the new prompt change, that is unlikely.
People don't always read the prompt paying attention to every word of
it, and "all" is a valid wildcard anyway.
> >> As I noted in the bug, most of the completions that would be
> >> provided by read-file-name-internal don't work
> >
> > IMO, that's okay, because wildcards cannot be meaningfully completed
> > on.
>
> But the aliases from grep-files-aliases can be meaningfully
> completed. I don't see why we shouldn't provide meaningful
> completion if the user defines a lot of aliases, seeing as how
> the current file name completion is useless.
I didn't think allowing it to complete on 2 non-file values is
important enough to justify the possible confusion.
prev parent reply other threads:[~2017-10-10 7:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-27 7:01 bug#28615: 25.3; rgrep, grep-read-files confusingly completes file names ヌエルモリノ
2017-10-05 4:15 ` bug#28615: [PATCH] Clarify what grep-read-files wants Allen Li
2017-10-09 13:41 ` Eli Zaretskii
2017-10-10 4:43 ` Allen Li
2017-10-10 5:55 ` Eli Zaretskii
2017-10-10 6:51 ` Allen Li
2017-10-10 7:52 ` Eli Zaretskii [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83bmlfqw2m.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=28615@debbugs.gnu.org \
--cc=vianchielfaura@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.