update of jed-extra

[G. Milde]

On  5.07.05, Jörg Sommer wrote:
> G. Milde schrieb am Tue 05. Jul, 15:23 (+0200):
> > On  4.07.05, Jörg Sommer wrote:
> > > G. Milde schrieb am Mon 04. Jul, 11:12 (+0200):


> > > I see a problem with site-lib when having more than one package. We
> > > can't put them all in /u/s/j/site-lib, because it is to difficult
> > > to manage this melting pot. (Think of removing the slc files of a
> > > package)
> > 
> > I do not see the problem, it will never reach the unhandy size of
> > /usr/share/doc/. Also, every package knows what files is contains.
> 
> But not really what files are produced by the compile script. 
> 
> > Alternatively you could remove all scl files in site-lib and
> > re-preparse the remaining sl files.
 
> Not all packages must preparse their files (debconf selection) 

IMHO, this is a debconf abuse. There are 2 cases:

  1. the *.sl file(s) can be savely preparsed. 
     -> no special care needed.
  
  2. a *.sl file must not be preparsed because of preprocessor
     constructs like #if XWINDOWS
     -> add it to a list of not-to-be-preparsed *.sl files
        (make ini has already an exclusion list)
     
     Ideally, all such files will be patched to become
     "preparsable". We might make this a requirement for Debian
     packages.
	

The "compile" script should

    * delete all *.slc files in site-lib and jed-init.d
    * preparse all *.sl files in site-lib and jed-init.d, except the
      ones in the exclusion list.
    
And the following scenarios:


  a) install jed or xjed: call the "compile" script, also compile the
     relevant *.sl files in JED_ROOT/lib/.
       
  b) purge jed and xjed: remove all *.slc files.   
  
  c) install a package containing *.sl files:
  
     Try the compile skript in postinstall
     
         (x)jed is installed: the set of *.slc files is updated
     
         (x)jed is not installed, skip the preparsing. If jed is
         installed later, the files will become preparsed too.
  

  d) remove a package containing *.sl files:
  
     After removal, try the compile skript.

         (x)jed is installed: the set of *.slc files is updated
     
         (x)jed is not installed: calling the "compile" script fails, but
         there is no *.slc file, so there is nothing to do.
  
> and it can become heavy effort to rebuild all this.

When updating my home library, (88 sl files) with make-ini's
update_home_lib(), preparsing causes no noticeable delay, while the
documentation extraction takes about 3 seconds (on an old AMD K6 400 MHz).


> We can build the documentation upon buildtime. Any objections? 
> Can we build the dfa caches too?

The case is similar to the slc files: Why ship them, if they could be
built at install time.

The documentation is currently in 1 file per libdir, so to update it
when a package adds files, it should be rebuilt. 

Alternatively, a package could add its docfile to the Jed_Doc_Files in
jed-init.d/NNpackage.sl (this will slow down the online help a bit, as all
Jed_Doc_Files have to be scanned for help).


Home Lib
--------
 
> > > Your home-lib instead registers paths and changes variables without any
> > > request

> > The most obstruive variable change is Jed_Home_Directory (~ to ~./jed,
> > if this exists)
> 
> This causes a bug. home-lib sets Default_Jed_Startup_Script = ~/.jedrc
> which overwrites our setting (=NULL) in jed.conf. All what we expect with
> this setting is thrown away.


This is tricky.

I really want to change Jed_Home_Directory to ~/.jed, as 
  
   The value of this variable specifies the user's so-called home
   directory where personal jed-related files are assumed to be found.
     
(e.g. .jedrecent and templates/)
  
OTOH, I introduced the Default_Jed_Startup_Script = ~/.jedrc for
backwards compatibility (searching .jedrc in ~ if not found in ~/.jed)
per user request long before the abovementioned bugfix.
  
I might have to remove this bugfix and add a documentation:

  If your home directory contains the jed dir ~/.jed/, this will be
  used as Jed_Home_Directory. Move your .jedrc there.

Another option would be to patch site.sl never to load
JED_ROOT/lib/jed.rc instead of the Default_Jed_Startup_Script=NULL
workaround.

> > With home-lib.sl in jed-common, site-lib, local-lib, home-lib and the
> > .jedrc path could be set in jed.conf, rendering obsolete
> > 25home-lib.sl.

> No, you can't set it in jed.conf. If you do it there, it must be done
> before the files in jed-init.d/ get evaluated to firstly give the user or
> local admin a change to overwrite the files in the packages and secondly
> make the files from the packages are usable by the scripts. 

> But then you run into a problem that every lib-dir that becomes
> registred in jed-init.d/XYpackage.sl is prepended to
> jed_library_path(), which makes it impossible to overwrite files with
> /usr/local/.

The preference in jed-library-path should be

  home-lib, local-lib, package-specific, site-lib, lib

register_libdir() prepends the argument to the path, so jed.conf should

  register_libdir(site-lib)
  
  % run the scripts in jed-init.d
  
  register_libdir(local-lib)
  register_libdir(home-lib)


> This is also a reason, why home-lib should only provide the register
> function.

You convinced me. Maybe it could be a compromise, providing the register
function and sensible defaults for Jed_Home_Library, Jed_Local_Library
and Jed_Site_Library. Instead of the current require("home-lib");
the two liner

 require("home-lib");
 register_libdirs(Jed_Home_Library, Jed_Local_Library, Jed_Site_Library);
 
would provide the backwards-compatible action (register_libdirs will
loop over _NARGS).

> Following proposal:

I rather change home-lib.sl. than define a function in jed.conf.

Do your think the check and change of Jed_Home_Directory belongs to
home-lib or to jed.conf?


Günter

-- 
G.Milde web.de