update of jed-extra
Jörg Sommer
joerg@alea.gnuu.de
Tue, 5 Jul 2005 23:39:44 +0200
--gatW/ieO32f1wygP
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
G. Milde schrieb am Tue 05. Jul, 15:23 (+0200):
> On 4.07.05, J=F6rg Sommer wrote:
> > G. Milde schrieb am Mon 04. Jul, 11:12 (+0200):
>=20
> > > > > > No makefile,=20
> > > > > What kind of makefile should this be?
> > > > make install would help much
> > > Again, it would not make sense to install all of Jedmodes.
>=20
> > How should we select? How to know what's good and what's bad?
>=20
> If this is a problem for a Debian package, it will be even more of a prob=
lem
> 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.
>=20
> It might be an idea to add the dcdata.txt metadata files to the sources.
What's in this file?
> > > (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.)
> >=20
> > 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)
>=20
> 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. Currently
it is easy to remove all in site-lib/ what we didn't ship. But if more
than one package puts its files into site-lib/ and some package
precompile some not, I don't see a easy way to remove the files the
package has created.
> 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) and it can
become heavy effort to rebuild all this.
> > The precompile_libdir() can be used in the compile files.
>=20
> The last version of make_ini has this function as byte_compile_libdir().
>=20
> However, the functions from make_ini are seldom used, so bundling it with
> the libdir setup slows down jed startup unnecessarily.
ACK. This would be a better step.
We can build the documentation upon buildtime. Any objections? Can we
build the dfa caches too?
> > Your home-lib instead registers paths and changes variables without any
> > request
>=20
> It was made to facilitate the setup so the request by the user is
> a simple "requires".=20
But it is too much for the package system.
> > and without any patching it may register paths they aren't used. It's
> > too static.
>=20
> It checks for every path it registers, so nonexisting paths will not be
> added (while empty ones might).=20
>=20
> 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 =3D ~/.jedrc
which overwrites our setting (=3DNULL) in jed.conf. All what we expect with
this setting is thrown away.
$ HOME=3D/tmp/ xjed -batch
=2E..
loading /usr/share/jed/site-lib/ispell_init.sl
loading /var/cache/dictionaries-common/jed-ispell-dicts.sl
loading /usr/share/jed/site-lib/jed.rc.slc
Unable to load /usr/share/jed/site-lib/jed.rc.slc
Traceback: evalfile
/usr/share/jed/lib/site.sl:3034:command_line_hook:Open failed
Local variables for command_line_hook:
Integer_Type n =3D 0
Integer_Type i =3D 2
Undefined_Type file =3D Undefined_Type
Integer_Type depth =3D 0
Undefined_Type next_file =3D Undefined_Type
Undefined_Type tmp =3D Undefined_Type
String_Type init_file =3D "jed.rc"
Undefined_Type next_file_arg =3D Undefined_Type
Error encountered while executing command_line_hook
> > 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.
>=20
> 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.
OK, you can merge home-lib and usr-local, but jed-extra must stay alone
to make it possible some other packages can register before home....wait,
if we put all together a package can take a lower number and get
registered in the path stack after home. Your right, we only need one file.
> With home-lib.sl in jed-common, site-lib, local-lib, home-lib and the .je=
drc
> 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/.
This is also a reason, why home-lib should only provide the register
function.
Following proposal:
Index: jed.conf
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- jed.conf (Revision 57)
+++ jed.conf (Arbeitskopie)
@@ -17,6 +17,53 @@
% the user choice by debconf at install time. Remember to change this in=
=20
% the patched jed.rc file too.]
=20
+% taken form home-lib.sl (http://jedmodes.sf.net)
+% -----------------------------------------------
+% =20
+% * Prepend \var{lib} to the library path,
+% * evaluate (if existent) the file ini.sl in this library
+% to enable initialization (autoloads etc).
+% * set Color_Scheme_, dfa-cache- and documentation- path
+public define register_libdir(lib)
+{
+ !if (2 =3D=3D file_status(lib)) % directory doesnot exist
+ return;
+ =20
+ % jed library path
+ set_jed_library_path(lib + "," + get_jed_library_path());
+
+ % colors
+ variable path =3D path_concat(lib, "colors");
+ if (2 =3D=3D file_status(path))
+ Color_Scheme_Path =3D path + "," + Color_Scheme_Path;
+
+ % documentation
+ path =3D path_concat(lib, "libfuns.txt");
+ if (1 =3D=3D file_status(path))
+ Jed_Doc_Files =3D path + "," + Jed_Doc_Files;
+
+ % dfa cache
+#ifdef HAS_DFA_SYNTAX
+ path =3D path_concat(lib, "dfa");
+ if (2 !=3D file_status(path))
+ path =3D lib;
+ Jed_Highlight_Cache_Dir =3D path;
+ Jed_Highlight_Cache_Path +=3D "," + path;
+#endif
+
+ % Check for a file ini.sl containing initialization code
+ % (e.g. autoload declarations) and evaluate it.
+ path =3D path_concat(lib, "ini.sl");
+ if (1 =3D=3D file_status(path))
+ () =3D evalfile(path);
+}
+
+% Jed_Home_Directory is defined in site.sl, defaulting to $HOME
+% If Jed_Home_Directory/.jed/ exists, point Jed_Home_Directory there,
+path =3D path_concat(Jed_Home_Directory, ".jed");
+if(2 =3D=3D file_status(path))
+ Jed_Home_Directory =3D path;=20
+
% jed init.d
% ----------
%=20
J=F6rg.
--=20
[dpkg] We are the apt. Resistance is futile. You will be packaged.
--gatW/ieO32f1wygP
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)
iQEVAwUBQsr+IIZ13Cz2nwVYAQKFNQgAo7IkdAuugYijy/n3z+BrS4LZRQPBrI1a
i+qNBWVv0uN6TIWyyCCMyv4OIgQq9q6QoJF5mEXGcbVdNSceIAbEFb8hihLEmBjN
ZAaCfSdnyA4mucfciCWTyYTT5HDKii34dUgGV53azXD7Tvn9hFevNaWhCfvqVbAQ
EijSI/WhJDQsyA5kcZc/2WmVq+SSQKj2goIEfv8m6PLTO50EFNhaRsWDv1fSevTG
YDAotTvAv+heVsdZlKhaK11ZkhsfX+cwT353JGxpG9qmGuKb5X0eQ1GK+iy2xRby
/bB3Z4aDq5I7F7W5i0anMW+31AzJ5i+yD3ooop3gcPW9uuOlNt5S2g==
=3CdG
-----END PGP SIGNATURE-----
--gatW/ieO32f1wygP--