[Bash-completion-devel] Work-needing packages report for Oct 24, 2008

[David Paleino]

On Sunday 31 January 2010 13:46:02, Michelle Konzack wrote:
> Hello David,
> 
> Am 2010-01-31 09:01:51, schrieb David Paleino:
> > I believe we could drop that sentence from the description. Also, I can't
> > really say what our Policy currently is. I remember once we (or maybe
> > only I?) planned to only keep the infrastructure, and move completions in
> > the appropriate packages;
> 
> Generaly I agree with it, because currently I have nearly 3  times  more
> completiony as packages installed, and bash-completion is a memory hog.

But they're not loaded into memory. This is what the "have foo && {}" 
construct is for.

> > that would've meant losing "access" to the completions
> > and probably leaving them rotting around the net, I suppose.
> 
> Maybe we should work together with the  Pakage-Maintainers  or  upstream
> only in the sense of coordination.

Guess what, we're upstream, this is the upstream mailing list, and the mails 
reach also !Debian people ;)

However, I believe coordinating with maintainers is a no-go. We currently have 
158 completions in contrib/ (i.e. bash_completion.d/), and coordinating with 
that much maintainers is going to cause headaches after the first five 
minutes. I was in favour of this policy too, in the beginning, but then 
consider the maintainance burden we (as upstream) and I (as Debian maintainer) 
would have. That would just be crazy -- unless each project gives us commit 
access limited to the completion file, and each of us (the team members) 
focuses on some projects. But that's not going to work, at all :)

> > > Note 1: For any of my own packages  which  has  executables  I  have 
> > > an appropriated bash_completion file
> >
> > What do you mean by "appropriate"? I'm in the process of writing an API
> > document for bash-completion :)
> 
> If I code new commandline stuff (I have more then 80  Packages  now),  I
> create for each package a bash-completion-file and put it into
> 
>     /etc/bash_completion.d/
> 
> and I think, other packages should do the same.

That's what dh_bash-completion really does ;) -- read its manpage!

> It is realy annoying if I see, bash_completion sucks around currently 12
> MByte of memory.

That's not possible, really. Not all completions are loaded, unless you have 
ALL the commands available on your system.

> I am designing TablePC/PanelPC/Servers based on ARM9/11 architecture and
> here, wee have not the memory like in i386/amd64/sparc.

I understand :)

> Bash-completion is very usefull but it  should  be  striped  to  a  bare
> minimum.

There could be margins of improvement here -- but at the distribution level, 
not upstream. Distributions could provide a bashcomp-core, containing the bare 
minimum, i.e. /etc/bash_completion when we'll finish the code split, and 
bashcomp-data, containing all the things in contrib/ (which would be 
/usr/share/bash-completion/<something> in future).

> > We're already splitting things out of bash_completion, and... seems like
> > you missed the debhelper:
> >
> > bash-completion (20080617) unstable; urgency=low
> >
> >   [ David Paleino ]
> >   * New upstream release
> >     [..]
> >     - added extra/dh_bash-completion to ease future rewrite of bc.
> >     [..]
> >  -- Luk Claes <luk at debian.org>  Sat, 21 Jun 2008 21:59:43 +0200
> 
> Oops I was not aware of this...

Bad Michelle, bad. :P

> [..]
> > > Bug#121631: enable expansion inside `which *`
> >
> > $ TEST=`which b<TAB>`
> > $ TEST=`which bin/`
> >
> > Which is obviously wrong. (bin/ is a directory I have in $CWD, not a
> > command in $PATH)
> 
> OK, but should be nt difficult to fix

Can't tell, will look after my exams. Or if someone from the team steps up..

> The following BUG sounds realy weird, because:
> > > Bug#320390: bash: Does not tab complete a file created after tab is
> > > pressed
> 
>                                                    ^^^^^^^^^^^^^^^^^
> This mean, bash_completion must guess, which file will be created in the
> future...  :-D  sounds like magic!

Exactly :)
Or, reload itself someway, or other such nasty things I'm not willing even to 
think about.

> > > Bug#467231: bash_completion is big and loads slowly; load-by-need
> > > proposed -> Ack!
> >
> > We're already planning on merging with bash-completion-lib, probably
> > targetting 3.0.
> 
> I was trying t get this running for more then one year and stoped...

We have its author (Freddy Vulto) in the team, and one of our targets is merge 
both projects.
However, there's a package for it in Debian, if you're willing to try it.

> > Wontfixes:
> > > Bug#393338: tab completion should show dirs in blue and executables in
> > >  green -> wontfix
> 
> Hmmm this could be possibel, because I have a  (bash)  commandline  tool
> which does this already, but it has to detect the type of the terminal.

I believe this could be something bash or readline related. We're really 
calling "compgen", not outputting anything ourselves.

Have a nice day,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|----
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20100131/a795ed15/attachment.pgp>