Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

man xyz stays xy if directory with same name present #420

Open
jidanni opened this issue Jun 6, 2020 · 4 comments · May be fixed by #787
Open

man xyz stays xy if directory with same name present #420

jidanni opened this issue Jun 6, 2020 · 4 comments · May be fixed by #787

Comments

@jidanni
Copy link
Contributor

jidanni commented Jun 6, 2020

$ man apti<TAB>

correctly becomes

$ man aptitude
aptitude aptitude-create-state-bundle aptitude-curses aptitude-run-state-bundle

However

$ mkdir /tmp/aptitude
$ cd /tmp/
$ man apti<TAB>
aptitude/ aptitude/ aptitude-create-state-bundle aptitude-curses aptitude-run-state-bundle

  1. Does not at least complete to "aptitude", but instead stays "apti".
  2. Gives two "aptitude/"
@scop
Copy link
Owner

scop commented Jun 9, 2020

Reproduced, interesting.

@maxnikulin
Copy link

A real world example: Ubuntu switched from deb to snap for browser packages (firefox, chromium), so users almost inevitably have ~/snap/ folder. A command to manage these packages is named snap as well. If CWD is ~ then hitting TAB while typing man snap causes manifestation of this issue.

scop added a commit that referenced this issue Aug 20, 2022
If a directory with the same name as an already found man page candidate
from manpath is present, they both end up in completions as a duplicate
with the trailing slash included.

To work around, skip file based completion altogether when a man page
from manpath is among found candidates. A workaround for the workaround,
i.e. "forcing" file based completion, is to prefix the argument with a
`./`.

Closes #420
@scop scop linked a pull request Aug 20, 2022 that will close this issue
@scop
Copy link
Owner

scop commented Aug 20, 2022

I don't have good ideas offhand how to fix this.

Getting rid of the duplicate would be fairly easy, but it'd get rid of the command, leaving only the dir with the trailing slash present. I think this is not what people would generally expect.

We could opt to not completing filenames if we've found some completions already. PR #787 implements that, at the expense of not doing filename completions at all if a matching man page from manpath has already been found. I'm not entirely happy with that either, because it will hurt also the vast majority of use cases where there are no problematic duplicates present.
Then again, the use case mostly affected by this would be the second manpage argument to man and subsequent ones, which is a quite rare one.

@maxnikulin
Copy link

A workaround to force filename completion is M-/, so ./ prefix is not necessary. However the problem of combining filename and non-filename completions is more general, see e.g. scp where colon without space should be added to host names while files and directories should be handled accordingly to regular rules. Unfortunately the scp code is not really robust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants