update of jed-extra

[Jörg Sommer]

--wULyF7TL5taEdwHz
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

G. Milde schrieb am Mon 11. Jul, 10:16 (+0200):
> On  8.07.05, J=F6rg Sommer wrote:
> > G. Milde schrieb am Thu 07. Jul, 11:36 (+0200):
> > > On  6.07.05, J=F6rg Sommer wrote:
> > > > G. Milde schrieb am Wed 06. Jul, 12:39 (+0200):
> > >=20
> > > Preparsing files is a sensible default. If a file poses a problem, the
> > > admin could set it on the exclusion list in jed.conf.
> >=20
> > Do you mean, we should not give the admin the option to preparse or not?
>=20
> No other than a custom variable for an exclusion list. Checked in
> byte_compile_libdir(). Used for the problematic cases mentioned below.

OK, this should be realizable.

> > we should do it? Mmmh, are there any disadvantages of preparsing?
>=20
> You loose the ability to do runtime decisions with preprocessor
> directives like #ifdef or #ifexists, e.g.

OK, this is known.

> > I don't know how to find dfa cache files, whose name
> > is set inside a SLang file.
>=20
> This is a different problem, you could only grep in the SLang files.

This is ugly.

> However, both, slc files and dfa files are actually just "secondary"=20
> (temporary) files. A purist would place them under /var/.

I think no. FHS says /var/ is for runtime data files which are files
changed at runtime. This isn't the case with slc and dfa.

> Is there a way to tell dpkg that *.dfa files are of no special
> importance and can be savely removed when removing the containign dir?

No. You need to clean up the directory before package remove (prerm
script), otherwise dpkg will grouse the directory is not empty.

This is the reason, we need to clean up the directory, but we can't
chose the brute force variant (rm *.dfa *.slc), if we share the
directory with other packages.

Because this, I say, we need different directories for different
packages.

> > > > > jed.conf should
> > > > >=20
> > > > >   register_libdir(site-lib);
> > > > >   % run the scripts in jed-init.d (might register more libraries)
> > > > >   register_libdir(home-lib, local-lib);
> > > >=20
> > > > But if a site admin decide to use a patched version of a file used =
in
> > > > jed-init.d is version get not recognized.=20
> > > Do you mean: if a file in jed-init.d should use a file in local-lib or
> > > home-lib instead of site-lib?
> > Yes.
> >=20
> > > 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.
> >=20
> > Why? If we register local-lib and home-lib in 30XX.sl it is still
> > possible to register some mode, they can be overwritten in >30XX.sl
>=20
> With this scheme, we had in jed-init.d
>=20
>    00XX.sl        % files that might register package libraries
>    ...
>    29XX.sl
>    30home-lib.sl  % register local-lib and home-lib
>    31XX.sl        % files that can easily use modes from local-lib and
>    ...            % home-lib but not register package libraries
>    99XX.sl	 =20
>   =20
> I do not see the need for files >30XX.sl.

Me too, but 50jed-extra-init.sl and 55ispell.sl exists. :)

One reason might be autoload() definitions.

> Debian packages should not need to use home-lib

I think we should support ~/.jed/. BTW: Why I need to place lib/ below
~/.jed/ for home-lib? I think it should be enought to have the lib stuff
in .jed/.

> or local-lib. The sysadmin can put the configuration in jed.conf
> instead.

ACK.

Have a good night, J=F6rg.
--=20
"Computer games don't affect kids. If Pacman would have affected us as
children, we would now run around in darkened rooms, munching pills and
listening to repetetive music."

--wULyF7TL5taEdwHz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQtLqsoZ13Cz2nwVYAQLC3AgAjHOzPv/Kro88tBhDPDAHafH7TETqfpS6
mZFBH/nJ2hh/GH8bnDfhxFvIXN9SzSUlq/WFjF//b40RY9nvVl314zEzfHmOJDLf
nanVB5yioLTkwvMPB22t/hgT+QiiJC0JSWKsWp3SBJzP9wvU4e59azzQdK7sdoR2
/c1VSW1g4tnHPxrEP3jFP2MjmG4GRdclLOVtK2f1N5OOATmj1i8VBTxiniT1iIFa
ViHsJLBZ0BYVQsfxU8i3Ct5g9bEoigo1U4GA1nJfJ5mq2Zrso4T1cBhUkQztzNCq
S4lL9VnNBbafjqHr2AIhrMKMAYVSKtbqZ/b9ebWUyj34LmNOroJWCA==
=spqH
-----END PGP SIGNATURE-----

--wULyF7TL5taEdwHz--