1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
$Id: TODO,v 1.1 2006/03/01 16:19:26 ianmacd Exp $
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
|
