-
Notifications
You must be signed in to change notification settings - Fork 391
feat(__load_completion): search more paths based on the command location #696
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
Conversation
I'm sorry. I just made a mistake. I intended to open a PR in my local repository for testing purpose. |
__load_completion
__load_completion
Just wondering if this was reopened on purpose, at least there are some conflicts to be resolved... |
d0ae589
to
41114d1
Compare
Ah, sorry for confusing you. I reopened this on purpose, rebased it, and planned to add a description, but I became busy and left it in the current status [Note: GitHub seems to disallow/unrecognize the rebasing of the closed PRs, so I needed to reopen the issue before I push the rebased commits]. I had actually already completed the rebasing in my local repository but intended to push it after I add descriptions of the PR. However, I forgot the details of the PRs so need to take the time to look at it again. Now I have pushed the rebased commits, but it's not ready for review because I haven't added descriptions of the PR. |
I have converted this to Draft PR. I'll later add the description and make it again a (normal) PR. The original reason that I decided to reopen the PR at this timing is that I wanted to use |
41114d1
to
f72afca
Compare
f72afca
to
ff4c3f6
Compare
ff4c3f6
to
b0020d6
Compare
I think this is the time to revisit this PR. I actually forgot about the details of the backgrounds, but now I think the code/doc change tells everything essential about the change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I support the general idea here, but I believe we should adjust the search order a bit, and I'm also worried about how complex the docs are becoming (most of the comments arise from that, I hope you don't take them too negative).
ae26eaf
to
849bf32
Compare
Co-authored-by: Koichi Murase <myoga.murase@gmail.com>
* doc(README): rephrase description of the search-order change * fix(README): mention `$PREFIX/sbin` in the search path * fix(README): fix a missing word "visible" * doc(README): describe the search order Co-authored-by: Ville Skyttä <ville.skytta@iki.fi>
* now multiple paths can be specified to BASH_COMPLETION_USER_DIR separated by colons. * search the completion file with the installation prefix extracted by $(_realcommand CMD). * search completion files with the installation prefixes extracted from $PATH.
This swaps the lookup order of in-tree (relative to the main script) and system data dirs. By checking in-tree completions first, before system data dirs, we support setups running directly from a git clone better, and have a more robust setup in any case. The main script and in-tree completions should stay in sync. There might for example be internal API changes between releases which wouldn't work if the main `bash_completion` and the set of completions we ship were from different versions, e.g. from git and a release. Refs scop#537 (reply in thread) * fix(__load_completion): swap order of in-tree and bundled completions
02926c0
to
1984040
Compare
rebased & squashed |
Thank you for reviewing and merging the PR! |
No description provided.