update of jed-extra

[Jörg Sommer]

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

G. Milde schrieb am Wed 06. Jul, 12:39 (+0200):
> On  5.07.05, J=F6rg Sommer wrote:
>=20
>   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)
>     =20
>      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. 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.

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.

> The "compile" script should
>=20
>     * delete all *.slc files in site-lib and jed-init.d

=2E..that it build before. A compile file of a package should not remove
files it is responsible for.

And I would not preparse the files in jed-init.d, because a admin may
make changes there.

> And the following scenarios:
>=20
>   a) install jed or xjed: call the "compile" script, also compile the
>      relevant *.sl files in JED_ROOT/lib/.
>       =20
>   b) purge jed and xjed: remove all *.slc files.  =20

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.

> > We can build the documentation upon buildtime. Any objections?=20
> > Can we build the dfa caches too?
>=20
> 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 !=3D 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.

> The preference in jed-library-path should be
>=20
>   home-lib, local-lib, package-specific, site-lib, lib
>=20
> register_libdir() prepends the argument to the path, so jed.conf should
>=20
>   register_libdir(site-lib)
>  =20
>   % run the scripts in jed-init.d
>  =20
>   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. 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.

> > This is also a reason, why home-lib should only provide the register
> > function.
>=20
> 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
>=20
>  require("home-lib");

Why not evalfile("home-lib.sl")? What's the advantage of require?

>  register_libdirs(Jed_Home_Library, Jed_Local_Library, Jed_Site_Library);
> =20
> would provide the backwards-compatible action (register_libdirs will
> loop over _NARGS).

Do you gain time, when looping over the whole function body than calling
the function again.

> > Following proposal:
>=20
> 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?

--=20
"Hey, dad, you see how this man can twist his fingers? Amazing, isn't
it?" "No, son, not really. He's been using Emacs for ten years..."

--6TrnltStXW4iwmi0
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)

iQEVAwUBQsvkw4Z13Cz2nwVYAQLKiggArp8TRIS7bf6j/QTL9j2huCuWqp2+2i2h
JDhdPoV0r8D455OyWgTwuZoCe9iz4+cZSXRo8WdmQVQF5CLcppIYx8JOulSvdEpH
bEhxXOsjajRKizdKDy1By/ZF+GpWZdiwPXz8KYzHAKpqmwRfDc2uUV1qHvR/rRLa
HJ7MBlun/DLM1ioy68uzQgp7xKW/8GkerIBdgC018DWqemf/34EF3O7oQflZ+55D
J/gBWkGSP7/lwxeqRe6hmrabQKZ/Nb7p969ldo3XXk/xV2uGlXQXxP9WzJ8vu7x/
VfSxHpKfjnDQLK73EeWEmhu4SwhKdPSUbN7v7YDw8et8RZP6EAZjYA==
=vttH
-----END PGP SIGNATURE-----

--6TrnltStXW4iwmi0--