54 lines
2.4 KiB
Plaintext
54 lines
2.4 KiB
Plaintext
bash completion needs to be rewritten from the ground up.
|
|
---------------------------------------------------------
|
|
|
|
bash completion really needs to be rewritten from the ground up, using all of
|
|
the features available in bash 3.1 and without regard for compatibility with
|
|
the 2.x line.
|
|
|
|
At that time, it should be split into multiple files for easier source
|
|
management. Whether or not it is actually installed on the destination
|
|
computer as separate files is a matter for future debate.
|
|
|
|
If it were installed as tens or even hundreds of files, each of which had to
|
|
be opened to decide whether it should be sourced in its entirety, that could
|
|
prove very expensive on some systems.
|
|
|
|
Alternatively, a master file could decide which of the individual completion
|
|
files should be sourced. In that way, we wouldn't need to open extra files
|
|
just to ascertain that the commands for those functions aren't on the system,
|
|
anyway.
|
|
|
|
A further alternative is that a build process be created, which would
|
|
concatenate the various files into a single completion file, similar to what
|
|
we have now. This option is my least favourite, because a system with a lot of
|
|
packages installed currently has to deal with sourcing over 200 kB of bash
|
|
code for each invocation of an interactive shell.
|
|
|
|
An even better alternative would be if bash supported dynamic loading of shell
|
|
functions (in the manner of zsh), but I don't believe there are any plans to
|
|
add this feature.
|
|
|
|
|
|
bash completion needs a better development environment.
|
|
-------------------------------------------------------
|
|
|
|
Currently, the bash completion project is managed by a single person: me. This
|
|
is how it has been since its inception back in the first half of 2000.
|
|
|
|
This way of working is now showing signs of severe strain. For quite some time
|
|
already, I have been unable to devote enough time to the project and, as a
|
|
result, it has suffered. In particular, releases in the past twelve months
|
|
have been few and far between. The 20060301 release is the first in more than
|
|
six months.
|
|
|
|
Whilst there have been good reasons for my inability to devote more time to
|
|
the project, it shouldn't actually matter whether or not I am available. For
|
|
that reason, I am going to look at transferring the project to public CVS some
|
|
time in 2006. Patches will then no longer find that I am a single point of
|
|
failure, but will instead find their way into the code base via a small team
|
|
of core developers.
|
|
|
|
--
|
|
Ian Macdonald
|
|
Amsterdam, March 2006
|