update of jed-extra

[G. Milde]

On  6.07.05, Jörg Sommer wrote:
> G. Milde schrieb am Wed 06. Jul, 12:39 (+0200):
> > On  5.07.05, Jörg Sommer wrote:
> > 
> >   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.
> 
> But the admin can decide, not to preparse the files. 

Preparsing files is a sensible default. If a file poses a problem, the
admin could set it on the exclusion list in jed.conf.

> With the error in email, I had the problem, that the preparsed file did
> not report a useful line number. I decided to not preparse this files
> and got better results.

For debugging, you can place a line

_debug_info = 1;

at the beginning of the file. Jed will realise the file is changed and
not use the preparsed version. If you re-preparse, line-numbers are
still shown (at the expense of a longer slc file).
 
> I would give all packages with SLang files a debconf dialog to let the
> admin decide if the SLang files become preparsed or not (or the decision
> for jed-common) is used.

As I said, preparsing is a sensible default, so IMHO no debconf
question needed.


> > The "compile" script should
> > 
> >     * delete all *.slc files in site-lib and jed-init.d
> 
> ...that it build before.

OK, the algorithm to find related *.slc files from *.sl files is easy,
isn't it?
 
> And I would not preparse the files in jed-init.d, because a admin may
> make changes there.

No problem, outdated slc files are ignored by evalfile().

> > 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.   
> 
> This cause problems if you remove one of them. It's tricky to find out if
> the removed package is the last jed/xjed. Otherwise you remove the .slc
> files for xjed, if you remove only jed.
> 
> There is no need to remove the .slc files upon deinstallation of jed or
> xjed.

I see. So de-installation of jed-common should take care of removing
*.slc files?


---------------------

> > > 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.
> 
> IIRC, the problem with the slc files was that they can become broken if
> the were build with a slang version != the installed slang version.

> Building dfa file can take very long. This is time you can save at build
> time

> But I remember I had problems with dfa files build with another slang
> version. We can't build the dfa files at build time, otherwise we get the
> same problems like we have with SLang files.

So it is the same problem but my question was the wrong way: it would
be simpler to prebuild, but more secure to build at install time.


------------------------------

> > 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
      % scripts in jed-init.d might register more libraries
> >   
> >   register_libdir(local-lib)
> >   register_libdir(home-lib)
> 
> But if a site admin decide to use a patched version of a file used in
> jed-init.d is version get not recognized. 

Do you mean: if a file in jed-init.d should use a file in local-lib or
home-lib instead of site-lib?

Well, this is the prize we have to pay if we want packages to be able
to register their own libdirs. Otherwise this libdirs would take
precedence over local-lib and home-lib.

A more fine-grained support would be possible with a pair of functions:
add_libdir() vs. append_libdir().

> What if a user decide to place a newer version of ispell.sl in its
> home-lib. It never get loaded, because the ispell of site-lib is used,
> because home-lib comes to late to the path.

No, register_libdir *pre*pends its argument, so the last will be the
first.


> > > 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");
> 
> Why not evalfile("home-lib.sl")? What's the advantage of require?

evalfile() leaves stuff on the stack. Of course you can also use
() = evalfile() but it looks not so nice. Also, require only evaluates
once, a second call will not re-evaluate.

> > register_libdirs(Jed_Home_Library, Jed_Local_Library, Jed_Site_Library);
> > will loop over _NARGS).
> 
> Do you gain time, when looping over the whole function body than calling
> the function again.

I gain the (negligible) time needed for the function call. But the resulting
code is shorter (and in a clause, no braces are needed).

> > > Following proposal:
> > 
> > I rather change home-lib.sl. than define a function in jed.conf.
> 
> FullACK. But if you strip down home-lib (how I think) you get
> register_libdir().
> 
> > Do your think the check and change of Jed_Home_Directory belongs to
> > home-lib or to jed.conf?
> 
> jed.conf, because the admin should have the possibility to revert this
> change.
> 
> BTW: Why you append the color path in register_library()? Is there a
> reason to not prepend the path?

No, this is a bug. I'll fix it.

All done, see jedmodes.sf.net/mode/home-lib/ (may take some hours until
the CVS is synchronized).

Günter

-- 
G.Milde web.de