feat(_comp_compgen_filedir,_comp_compgen_filedir_xspec): don’t suggest . and ..

[Maelan]

This is a resurrection of #364, adapting to the current codebase, and addressing (I think) objections made there.

With this patch, file-and-directory completion provided by _comp_compgen_filedir and _comp_compgen_filedir_xspec do not suggest . nor .. nor */. nor */.. unless the user input is .. or */.. .

The condition can easily be changed from “unless the user has typed ..” to “unless there is only one suggestion” (just replace if [[ "${cur}" != @(..|*/..) ]] by if (( ${#toks[@]} > 1 )) ).

The motivation is to be able to tab-complete hidden files with more comfort: as hidden files are relatively rare, it is not uncommon to have no more than one hidden file in a given directory (or, in the case of a git repo, hidden files with a common prefix: .git, .gitignore…). It should then be enough to type just the dot and get the hidden file completed. Especially considering that typing a letter after a dot is uncomfortable, depending on your keyboard.

But . and .. are always there and get in the way of completion, despite being uninteresting suggestions: . alone can never get a slash appended, because it is always a prefix of the suggested .. ; and .. is strictly easier to type by pressing the dot key twice than by pressing the dot key, then whatever key is used to trigger completion.

There is one use case for suggesting .. though: in the previous PR, it was mentioned that some users may want to rely on completion to append a slash after they have typed .. ; so we must still suggest .. in some cases, which is what the “unless” condition addresses.

Another use case mentioned in the previous PR is that some users might(?) want to type . and expect bash-completion to complete it to .. ; this use case does not work with this patch, but it does not work without, either, because . itself is a valid suggestion too… So we are not degrading user experience in any way. We might support this use case with a more complex logic (always prune . ; prune .. unless [condition]).

If, barring all this, the feature is judged too disruptive a change, perhaps the new behavior could be controlled by a user option?

Implementation note: I’d have preferred to use the builtin filtering feature of compgen/complete (-X '@(.|..|*/.|*/..)') but it does not combine with filtering a custom xspec (we cannot use -X twice; there is a comment about that in _comp_delimited).

Regards,

[akinomyoga]

Implementation note: I’d have preferred to use the builtin filtering feature of compgen/complete (-X '@(.|..|*/.|*/..)') but it does not combine with filtering a custom xspec (we cannot use -X twice; there is a comment about that in _comp_delimited).

Technically one could do that by -X '!(!(pat1)|!(pat2))', but it is practically extremely slow due to Bash's implementation of extglob. (edit: Hmm, in this case, I think you want to remove candidates matching either pat1 or pat2, so you can simply do -X '@(pat1|pat2)'.) You can instead call compgen again for additional filtering by -X.

[akinomyoga]

There is a test failure in CI.

Also, can you add tests for the new behavior (in test/t/unit/test_unit_compgen_filedir.py)?

[scop]

I haven't had a real look here yet, but let's add the full rationale from the MR description to the commit message so one does not need to go search GitHub for it later.

[akinomyoga]

rebased

[akinomyoga]

I added necessary fixes. Each change is separated now, but they can be squashed before merging.

There is a test failure in CI.

7b4c531

Also, can you add tests for the new behavior (in test/t/unit/test_unit_compgen_filedir.py)?

I added them by myself f11c887.

I haven't had a real look here yet, but let's add the full rationale from the MR description to the commit message so one does not need to go search GitHub for it later.

I updated the commit message in 0973b43 (along with the first-line fix for Conventional Commits).

[akinomyoga]

squashed

[yedayak]

I pushed 88894da to add some testing for completing ..something files, I can squash if anyone thinks that's necessary. In general I'm in favor of this change.