update of jed-extra

[G. Milde]

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

> 
> > > > > No makefile, 
> > > > What kind of makefile should this be?
> > > make install would help much
> > Again, it would not make sense to install all of Jedmodes.

> How should we select? How to know what's good and what's bad?

If this is a problem for a Debian package, it will be even more of a problem
for a "generic" repository. That is why there is no install script, the
"release" is for simple download and hand-picking of modes to install.

It might be an idea to add the dcdata.txt metadata files to the sources.

 
> > > > > no copyright notice (this might cause trouble with Debian)
> > > Can you add a COPYING file to the tar.gz?

Done.

 
> > > > > * why does the old version of 05home-lib.sl take care of site-lib?

> > ... jed (unfortunately) doesnot care about extensions on a
> > higher level than providing set_jed_library_path and Jed_Doc_Files and
> > Color_Scheme_Path and Jed_Highlight_Cache_Dir and ... to be used in
> > .jedrc or jed.conf.
> 
> I think this is enough.

It took me some years of jed use to realise all of the things needed to
set up a private extension library. Once I found out, I wrote home-lib.sl. 
Now, it is just one line in .jedrc (for the average non jed-extra user)

require("home-lib", "/FULL_PATH_TO/home-lib.sl")



> > (This is why I want it to be in jed-common: it is usefull without all the
> > rest of jed-extra for both, the end user adding or modifying a mode as
> > well as other Debian packages providing a jed mode.)
> 
> 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.
Alternatively you could remove all scl files in site-lib and re-preparse
the remaining sl files.
 
> What comes into my mind is a collection of lib tools. It should provide 
> * a function register_libdir() to register a directory (excatly what is
>   done in home-lib.sl:register_library() -- BTW: the name is a bit
>   confusing, because with a library a .so file is assumed)

However, it uses set/get_jed_library_path()... 

Ok, I have to admit that many of jed's function names are not really
intuitive or transparent. I will change it to register_libdir().

> * and a function precompile_libdir() to build the .slc files and .dfa and
>   anything als what's done by make_ini.sl

> This libtool I would ship with jed-common (in /u/s/j/jed-common),
> because it does not do any action. 

make_ini.sl doesnot do any action when evaluated. So it is already (part
of) the proposed libutils.

> The precompile_libdir() can be used in the compile files.

The last version of make_ini has this function as byte_compile_libdir().

However, the functions from make_ini are seldom used, so bundling it with
the libdir setup slows down jed startup unnecessarily.


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

It was made to facilitate the setup so the request by the user is
a simple "requires". 

(This is no uncommon feature in jed, see iso-latin.sl, recent.sl,
numbuf.sl, ...)

> and without any patching it may register paths they aren't used. It's
> too static.

It checks for every path it registers, so nonexisting paths will not be
added (while empty ones might). 

The most obstruive variable change is Jed_Home_Directory (~ to ~./jed,
if this exists)

All in all, IMHO it doesnot do any harm. Also, for obvious reasons it is
tailored towards Debian compatibility.

Configuring is tricky, as home-lib is intended to be run even before
.jedrc (so that .jedrc can be moved into ~/.jed as a small contribution
to reduce the litter in ~). It checks environment variables and could
easily be extended to check custom variables as well (so that e.g.
jed.conf could set some variables and then require home-lib.


How about a custom variable of libdirs to register, say

custom_variable("Jed_Libraries", 
                [Jed_Site_Library, Jed_Local_Library, Jed_Home_Library]);
                
foreach (Jed_Libraries)
  register_libdir(());


This would be backwards compatible but allow evaluating of home-lib with
a custom set of libraries to register, e.g. 

variable Jed_Libraries = String[0];
require("home-lib");

would do nothing.


> Then we can install files /etc/jed-init.d/20jed-extra.sl to register
> /usr/share/jed/site-lib (or .../jed-extra) and 20jed-gtk.sl to register
> slgtk stuff and 23usr-local.sl to handle /usr/local/... and 25home-lib.sl
> to register ~/.jed/lib. Into the 25home-lib.sl I would also handle the
> .jedrc path.

Uff.  One of the main advantages of jed is its fast startup. I hate KDE
because I have to wait for every app as long as on windows. Jed starts
with virtually no delay and I will do everything I can to keep it
this way, trying to keep as low as possible the number of startup files.

I see the advantage for a package placing a file in jed-init.d but I do
not see the need for one package placing several files there.

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.


Günter

-- 
G.Milde web.de