Bug 7867 - commands should have tab completion
Summary: commands should have tab completion
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Bugzilla mail exporter
Depends on:
Reported: 2022-03-18 14:49 CET by Pierre Ossman
Modified: 2022-07-15 16:11 CEST (History)
2 users (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2022-03-18 14:49:24 CET
It is becoming somewhat ubiquitous that commands have tab completion/bash completion, so users will expect the same of us.

It will likely be commands with many options or arguments that benefit the most from this, like tlctl.
Comment 1 William Sjöblom cendio 2022-04-13 09:04:10 CEST
I had a look at different tools for providing shell completions in a
declarative manner based on the argument parser object.

• Ahead-of-time completion script generators
  • shtab <https://github.com/iterative/shtab>

    Completion script generation for argparse. Rather complex but
    noticeably faster than the alternatives below for obvious
    reasons. Supports both bash and zsh. Could possibly benefit
    from more granular phase separation complexity-wise.

• Completion performed by the script itself
  • argcomplete <https://pypi.org/project/argcomplete/>

    Completion for argparse. Seems to be relatively widely used by
    individuals using many argparse but seldom bundled with other
    packages. Has good test coverage. Only first-class support for bash.
    Relatively slow but gives the programmer an easy time providing
    rich completions.

  • optcomplete <https://furius.ca/optcomplete/>

    Completion for optparse (the library currently used). Supports only
    Python 2 and does not look very promising at a first glance as the
    code is both unmaintained and littered with TODOs and has close to
    zero test coverage. Nonetheless it may have some good parts/ideas
    and is relatively compact. Supports both bash and zsh.

So, the main trade-off that has to be made is between performance/low
coupling and extendability/completion richness. The approach of spinning
up a python interpreter for every completion also makes supporting 
multiple different shells easier. Also, note that we are running
M.2 drives in our workstations and that the python start-up time on our
machines are very fast compared to others when reasoning about the
overhead of spinning up a python interpreter for every completion call.

Note You need to log in before you can comment on or make changes to this bug.