Future of shell completions
With the implementation of #685, shell completions no longer work except when invoked through the legacy symlinks. Also, they can only be generated by the
mkcompl script, which requires the symlinks (and likely requires some updates to work correctly in the presence of the
gmx binary). If we want to remove those symlinks alltogether in the future, then the completions will become useless.
https://gerrit.gromacs.org/#/c/2590/ contains RFC changes for implementing basic completion functionality for the wrapper binary, but has not received a single comment in the four months it has been out there. Currently, it only implements the completions for bash. IIRC, the last time the completion machinery was modified was some time in the early 2000's.
We should decide what we want to do with this and how much effort we want to spend here. In addition to the wrapper binary, another thing that requires a complete overhaul of the machinery that generates the completions is the use of the Options machinery for command-line parsing. We are not far from being able to extend https://gerrit.gromacs.org/#/c/2932/ to cover also the command-line parsing.Possible alternatives:
- Drop the completions completely.
- Keep basic completion facilities, but only generate them for a single shell (e.g.,
bash, since that currently works).
zshshould be able to use
bashcompletions more or less directly. The only way to implement such complex completions for
tcshis a custom script, so that script could also redirect the actual work to a
- Keep generating separate completions for the different shells. This requires someone who actually knows these shells to pitch in with the implementation, since I only have experience with
zshseems ultra-flexible, and I could try to do something there. But
tcshis quite limited, so it can be difficult to get the same level of functionality there as for the other shells, and I don't have particular interests there. One option is to also just drop the
tcshcompletions if no one is interested in maintaining those.
Shell completion export from the wrapper binary
Bash completions now complete the arguments to the wrapper binary
itself, as well as the subcommand names. After a subcommand has been
specified, use the existing completion logic. Completions now work also
for arbitrarily suffixed binaries (which the old system didn't work at
all). No completion is generated for symlinks, but should be
straightforward to do if really required; approach would be the same as
Other completions are not working for the wrapper binary, and as far as
I can tell, require a completely different approach. Removed the
Fixes to filename shell completions
- When completing a file name, don't add a space after a directory name
has been completed.
- Don't exclude directory names starting with . from the completions.
This also excludes ../foobar/.
- Use a more reasonable pattern to match the file names: expect exactly
one of the acceptable extensions, and at most one .gz/.Z extension.
- Complete directory names for mdrun -multidir.
Issues that remain:
- Completions for paths that contain spaces doesn't really work.
The only difference to earlier behavior is that now, completing
something that starts with a " gets an appended space before the
- When completing to subdirectories, the list of possible completions
shows the subdirectory for each alternative. This doesn't happen with
standard bash completion. Not sure whether this is feasible to fix.
Shell completions through Options
- Implement shell completion generation for command line options
specified through an Options object.
- Use this support to generate the list of options for the wrapper
binary instead of hardcoding them.
- Use this support and the conversion from t_pargs/t_filenm to Options
to generate the existing completions. The only differences in the
generated completions are in the order of the options and in changing
"$n == 1" to "$n <= 1" and ".
(xtc|trr|...)" to "(.xtc|.trr|...)".
- Extend some of the options to expose information necessary for this.
#4 Updated by Szilárd Páll over 4 years ago
I think completition is rather useful for non-expert users and even I, with my moderate amount of experience, find it great that pressing TAB when looking for an input file will show me e.g. only the three tpr-s that are relevant as input instead of all 300 files in the respective directory.
Regarding the issue of providing full and tested functionality with multiple shells, this is IMO an ideal task to get help with from the GROMACS community. At least for bash and csh there should be people interested and willing to help - they may need some poking, though.
#7 Updated by Teemu Murtola over 4 years ago
https://gerrit.gromacs.org/#/c/2590/ now contains a relatively finished implementation of automatically generated bash completions. Other completions are simply dropped, since as far as I can tell, they require a completely different approach than what was used previously. I can provide support (e.g., refactor shellcompletions.cpp to more easily support export in multiple different formats) if someone gets to actually implement this for other shells. I'm not planning to do more for now; let's just wait for those contributions come flowing in…
If people really feel that this is such a great feature, it would be nice to get some review comments as well.