Required packages for gdbmrecent

Rafael Laboissiere rafael at debian.org
Mon Feb 5 16:05:07 CET 2007


[replying to pkg-jed-devel]

* G. Milde <g.milde at quantentunnel.de> [2007-02-05 10:30]:

> On  4.02.07, Rafael Laboissiere wrote:
> > A quick question:  If I put in my .jed/jed.rc:
> 
> >     require ("gdbmrecent");
> 
> > it does not work.  I need to put instead:
> 
> >     require ("bufutils");
> >     require ("sl_utils");
> >     require ("gdbmrecent");
> 
> > Shouldn't the two first lines be present in gdbmrecent.sl?
> 
> Not really. I'd rather use autoloads for the needed functions (or, to
> cite /etc/jed.d/50jed-exra.sl:
> 
>   % alternatively evaluate the utils/ini.sl file (or set the "initialize"
>   % argument to 1 in append_libdir($1 + "utils/", 1) above)
>   % () = evalfile("utils/ini.sl");     % autoloads for all utility functions
> 
> 
> (BTW, all "utils" autoloads are loaded with 50jed-extra-full.sl instead of
> 50jed-extra.sl in /etc/jed.d/.)
> 
> The point is that gdbmrecent will be evaluated right at the startup while
> it might be used either later or never, so autoloads (instead of require)
> can keep the startup time small. (Remember, the "instant startup" is one
> of the main advantages of Jed.)
> 
> We had a lengthy discussion with Paul Boekholt (the gdbmrecent author) about
> require() as well as autoload() and where to put these. It is his
> understanding, that the right place is not in the individual modes (where
> there is a lot of duplication) but in the setup file(s).
> 
> As a consequence, jed-extra has autoloads for the "Boekholt-modes" that
> are activated by default in jed.d/50jed-extra.sl
> (
>   % add some autoloads 
>   autoload("push_defaults", "sl_utils");    % needed by ispell_init.sl, complete, occur, ...
>   autoload("string_nth_match", "strutils"); % needed by hyperman.sl
>   autoload("get_keystring", "strutils");    % needed by snake.sl
> )
> where they are less intrusive and easier to maintain and extend than in
> debian-patches.
> 
> What shall we do with jed-extra to prevent the "unexpected behaviour"?
> 
>   * add required autoloads to 50jed-extra.sl,
>   * add documentation (where?)
>   * move gdbmrecent to the "extra" section, where it is (or should be)
>     clear that extra setup might be needed?

I would prefer the first solution (adding autoloads).  The gdmrecent module
will ultimately replace the jedstate package, so it has to work out of the
box.  The jedstate package, besides being obsolete, is in a very bad shape
(e.g. Bug#406815).  Even worse, it has been orphaned by its maintainer on
Sep 2, 2006.

My plan is to make the DJG adopt the package and transform it into a
transition package, which will "Recommends: jed-extra" and include a tool
for converting ~/.jedstats.db into ~/.jed/recent_db.  I think that following
down this path is better than simply removing the jedstate package from the
Debian distribution, since this package was relatively popular [1].

So, Günter, could you please add the required autoloads to 50jed-extra.sl?

-- 
Rafael

[1] http://people.debian.org/~igloo/popcon-graphs/index.php?packages=jedstate



More information about the Pkg-jed-devel mailing list