Improved apt/dpkg completion and completion hacking questions

Improved apt/dpkg completion and completion hacking questions

[Hannu Koivisto]

[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]

Greetings,

I noticed that the completions you get in
'apt-get install <C-d>' are not only packages available for
installation but all known package names.  At the same time it
occurred to me that it would be very cool if package names were
accompanied by their short descriptions (what's right after
"Description:" in dpkg -p package-xyz).

So I modified _deb_packages_update_avail to generate proper
packages with descriptions (and reindented _debs_caching_policy
since it seemed to be indented oddly).  I didn't modify other
_deb_packages_update_* functions to generate descriptions because I
thought descriptions wouldn't be so valuable in those cases and
also because I wasn't sure how to best generate them efficiently
(then again, maybe efficiency wouldn't have been such a big issue
anyway, especially if caching is used (though apparently caching
isn't enabled by default)).  This resulted to an if-then-else to
the place where arrays generated by those functions are actually
used to add completions.  Patch against zsh 4.2.5 is included as an
attachment.

I'm using awk to generate the list of packages plus descriptions.
I've seen other completion code to use awk as well, but I wonder
how accepted that is generally?  The change also increases memory
consumption (from 800kB to ~3MB in one test case).  Aside from
removing the commented out old code, what would I need to do in
order to get my changes accepted to the zsh distribution?  This
brings us to customization; not because I'm suggesting it as the
way to make the change more acceptable, but for educational reasons
:)  I'm sure it would be possible to generate the list without awk
(though I suspect not quite as efficiently) but let's pretend it
isn't.  But we still have the old way of generating completions
without descriptions without awk.  So, let's say we make the old
code the default behaviour and have the description-generating awk
version available via customization.  How would you implement such
customizability?

Another unrelated question.  The stock _deb_packages uses compadd
directly to add the completions.  And higher level code that calls
_deb_packages knows this and passes parameters to be passed to
compadd, including -X and its value.  As far as I can see, -X's
value corresponds to the DESCR parameter of _describe, which I
figured would be the right choice for adding completions with
descriptions.  Since _describe also accepts options to be passed to
compadd, I thought I wouldn't try to parse -X out of compadd
parameters passed to _deb_packages and pass its value as DESCR but
instead I pass an empty string as DESCR and give all compadd
parameters to _describe.  Apparently this works, i.e. -X in compadd
parameters overrides DESCR, but since this behaviour isn't
documented, I'd like to know if I'm doing to right thing here?

-- 
Hannu

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: _deb_package patch --]
[-- Type: text/x-patch, Size: 1513 bytes --]

--- /usr/share/zsh/4.2.5/functions/Completion/Debian/_deb_packages	2005-04-27 03:31:08.000000000 +0300
+++ _deb_packages	2005-10-16 20:21:31.000000000 +0300
@@ -6,10 +6,14 @@
   if ( [[ ${+_deb_packages_cache_avail} -eq 0 ]] ||
       _cache_invalid DEBS_avail ) && ! _retrieve_cache DEBS_avail;
   then
+    #_deb_packages_cache_avail=(
+    #  ${(f)"$(apt-cache --generate pkgnames)"}
+    #)
     _deb_packages_cache_avail=(
-      ${(f)"$(apt-cache --generate pkgnames)"}
+        ${(f)"$(apt-cache dumpavail | \
+                awk -v 'FS=Description: |Package: ' \
+                '/^Package: / { package=$2 } /^Description: / { print package ":" $2 }')"}
     )
-
     _store_cache DEBS_avail _deb_packages_cache_avail
   fi
   cachevar=_deb_packages_cache_avail
@@ -103,16 +107,20 @@
 
   _deb_packages_update_$pkgset
 
-  _tags packages && compadd "$expl[@]" - "${(@P)cachevar}"
+  if [[ "$pkgset" == "avail" ]]; then
+      _tags packages && _describe '' ${cachevar} "$expl[@]"
+  else
+      _tags packages && compadd "$expl[@]" - "${(@P)cachevar}"
+  fi
 }
 
- _debs_caching_policy () {
+_debs_caching_policy () {
     # rebuild if cache is more than a week old
-      oldp=( "$1"(mw+1) )
-        (( $#oldp )) && return 0
-
-	  [[ /var/cache/apt/pkgcache.bin -nt "$1" ||
-	     /var/lib/dpkg/available -nt "$1" ]]
-	  }
+    oldp=( "$1"(mw+1) )
+    (( $#oldp )) && return 0
+    
+    [[ /var/cache/apt/pkgcache.bin -nt "$1"
+       || /var/lib/dpkg/available -nt "$1" ]]
+}
 
 _deb_packages "$@"

Re: Improved apt/dpkg completion and completion hacking questions

[Clint Adams]

> without descriptions without awk.  So, let's say we make the old
> code the default behaviour and have the description-generating awk
> version available via customization.  How would you implement such
> customizability?

You could use 'zstyle'.  Another thing you might consider is
filing a wishlist bug on apt to add an option to spew out
the short description after each package name when doing
'apt-cache --generate pkgnames'.

Have you done any speed tests?

Re: Improved apt/dpkg completion and completion hacking questions

[Hannu Koivisto]

Clint Adams <clint@zsh.org> writes:

> You could use 'zstyle'.  Another thing you might consider is

I was hoping for slightly more detailed guidelines regarding zstyle
from the completion programmer's point of view...

> filing a wishlist bug on apt to add an option to spew out
> the short description after each package name when doing
> 'apt-cache --generate pkgnames'.

There would also have to be an option for generating only package
names of packages available for installation.

> Have you done any speed tests?

On a 2.8GHz P4 machine with plenty of memory and reasonably
fast/modern IO/disk apt-get install zsh<C-d> (for the first time,
i.e. when it fills the array) took about one second.  On my
memory-starved 466MHz Celeron machine it took about three seconds
if _deb_packages_update_avail had been run in another shell
recently.  If not, it took up to eight seconds (slow IO, probably
needed to swap stuff out as well).

I haven't yet figured out how to enable caching, which
_deb_packages seems to support.

-- 
Hannu