From: Daniel Mendler <mail@daniel-mendler.de>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 49776@debbugs.gnu.org
Subject: bug#49776: 28.0.50; Incorrect username completion results reported by `read-file-name-interal`
Date: Fri, 30 Jul 2021 15:22:18 +0200 [thread overview]
Message-ID: <4bd7f6ed-5e65-af35-1952-501a45fce8f1@daniel-mendler.de> (raw)
In-Reply-To: <8735rwm0ec.fsf@gnus.org>
On 7/30/21 2:50 PM, Lars Ingebrigtsen wrote:
> But you said it returned "/.config/~man" for you (while it returns
> "/.config/~man/" for me) (note trailing slash)...
Yes, this was a typo from my side, sorry for that. Please look at the
other examples I've sent.
So to describe this better: (all-completions "~/etc/~man"
'read-file-name-internal) returns ("/etc/~man/"). In contrast
(all-completions "/usr/~man" 'read-file-name-internal) returns ("man/").
"/etc/~man/ is neither a valid user name nor a valid file path. I have
the user "man" on my system of course (I am also on a recent Debian).
So the problem here is that in to even call the completion table with
"~/etc/~man", the completion boundary is placed such that the string
behind the first "~" is completed. If I read Eli correctly, he says that
this is the expected behavior, while I would have expected that the
completion boundary is placed behind the second "~", such that the
completion table does not return odd looking results like "/etc/~man".
Furthermore the string before the first "~" can be considered shadowed.
So maybe the problem here is not with the results returned by
`all-completions` but rather with the completion boundaries. I think
this needs further investigation from my side.
Daniel
next prev parent reply other threads:[~2021-07-30 13:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-29 22:17 bug#49776: 28.0.50; Incorrect username completion results reported by `read-file-name-interal` Daniel Mendler
2021-07-30 5:47 ` Eli Zaretskii
2021-07-30 11:47 ` Lars Ingebrigtsen
2021-07-30 12:29 ` Daniel Mendler
2021-07-30 12:50 ` Lars Ingebrigtsen
2021-07-30 13:12 ` Lars Ingebrigtsen
2021-07-30 13:31 ` Daniel Mendler
2021-07-30 17:18 ` Lars Ingebrigtsen
2021-07-30 21:45 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-31 12:07 ` Lars Ingebrigtsen
2021-08-02 11:57 ` Daniel Mendler
2021-08-04 6:13 ` Lars Ingebrigtsen
2021-07-30 13:22 ` Daniel Mendler [this message]
2021-07-30 12:45 ` bug#49777: " Daniel Mendler
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=4bd7f6ed-5e65-af35-1952-501a45fce8f1@daniel-mendler.de \
--to=mail@daniel-mendler.de \
--cc=49776@debbugs.gnu.org \
--cc=larsi@gnus.org \
/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.