fix: dotfiles excluded from tab completion

[elseawhy]

This pr fixes two distinct bugs that were causing dotfiles to be completely excluded from tab completion
( Closes #992 and #864 )

Bug 1:
Flyline's native filename expansion was hardcoded to always skip hidden files.

This pr allows flyline to read _rl_match_hidden_files directly from bash, it will now dynamically respect your standard bash config, users can simply add bind 'set match-hidden-files off' to their ~/.bashrc to stop dotfiles from showing.

Bug 2:
Even with the first fix, if a user had an alias like alias ls='ls --group-directories-first', flyline would expand the alias before asking Bash for completions. This is fine but if the user have bash-completion installed, which most users do, this will trigger a crude regex bug in bash-completion

In v2.18.0 of bash-completion, inside the generic _comp_complete_longopt function, bash-completion uses this exact code to guess what flags do:

            --!(no-*)dir*)
                _comp_compgen -a filedir -d;
                return
            ;;

Because --group-directories-first contains the word dir, the regex blindly assumes the user is trying to supply a directory argument to the flag, which forces compgen -d hiding all files

In this pr, flyline now detects self aliases, if the command is self aliased flyline will simply not expand it, which is exactly how native bash handles aliases, this prevents bug 2.

[elseawhy]

oh my god, i accidentally force pushed again ugh

[elseawhy]

I also removed should_skip_hidden cause it was redundant. When Flyline was using the glob crate to search the filesystem, if i understand correctly, should_skip_hidden was added to filter the dotfiles grabbed by glob in tab_complete_with_expanded_pattern

But on August 20th 2c1740e (PR #973), glob was removed from Flyline and switched to expand_iter(), since it already checks wants_hidden and filter the dotfiles, should_skip_hidden is simply not needed anymore

[HalFrgrd]

Thanks for the great fix again!

Do you think we should be observing bind 'set match-hidden-files off/on' or shopt -s dotglob ? I ask because I want to make sure the glob preview shows what bash will expand when running the command. e.g. If the user types ls ~/.* or ls ~/*, flyline will show the auto completions for each one. When they press enter, bash will expand the command before execution and it's important that what flyline shows in each case matches what bash will expand.

[elseawhy]

Yes, I think we could create a new PR for that later

Do you think we should implement exactly what bash + readline does?

Like iirc, if match hidden files on, dotglob off, hitting tab will show dotfiles but rm -rf * won't delete dotfiles, dotfiles are only deleted IF dotglob is turned on. If we are doing it this way, we just need to expose dotglob to flyline on top of this current pr.

Correct me if I'm wrong, but if we are going your route, eg only expand what is shown on tab completion, we just need to expose dotglob to flyline, match hidden files isn't needed anymore, but doing it this way means we have to filter the dotfiles expanded by CommandComp (completions generated by programmable completions) internally via flyline.

Right now in this pr, the dotfiles generated by CommandComp are filtered via readline, using the bind command that turns match hidden files off.

[HalFrgrd]

I spent some more time thinking about how things should work. I suppose there are three cases:

• For CompType::GlobExpansion (e.g. when the user types ls ~/*), we should observe set -s/u dotglob.
• For the CompType::CommandComp stuff, we shouldn't filter the results. We just show what we get back.
• For CompType::FilenameExpansion / CompType::FuzzyFilenameExpansion, we should try and make this act like how CompType::CommandComp would act in terms of whether or not to show dotfiles when we the word under cursor doesn't start with a dot. (e.g. when we type asdf <tab> and no completion spec exists for asdf, CompType::FilenameExpansion is triggered and we should generate suggestions like those generated for ls <tab> assuming ls has a comp spec setup).

Do you think this is sensible?

[elseawhy]

Sure we could do that, since we are not gonna filter it inside flyline, that means we have to keep rl_match_hidden_files right ?

[HalFrgrd]

I think we'll need rl_match_hidden_files for CompType::FilenameExpansion / CompType::FuzzyFilenameExpansion