slsh's require breaks jed-extra
G. Milde
milde at users.sourceforge.net
Fri Jun 8 07:02:28 UTC 2007
On 7.06.07, John E. Davis wrote:
> On Thu, 7 Jun 2007 "G. Milde" said:
> >I would prefer an optional "namespace" argument over the need to fix
> >all these 23 modes with a "compatibility switch".
> It has been my experience, that "feature" is not actually used except
> as a filename. In fact,
> require (filename [,namespace]);
> should work.
Learning that the `namespace' argument is optional, the number
broken modes comes down to 1 or 2. In the jedmodes-extra Debian package
the activation script /etc/jed.d/50jed-extra.sl needs fixing (see below).
> Earlier versions of the require function (e.g., the one distributed
> with 0.99-18) do not support namespaces. In this sense, there is no
> backward compatibility.
My problem is not the missing "namespace" support, but the use cases with
require(feature, filename)
where feature != filename.
> In what way are you using require?
Two use cases with <feature> != <path> are present in my local
extensions:
1. Requiring a feature from a file that is not on the jed library path:
/usr/share/jed/jed-extra/libdir.sl
%\example
% The following lines in jed.rc
%#v+
% require("libdir", "/FULL_PATH_TO/libdir.sl");
% add_libdir("usr/local/jed/lib/", 0)); % do not initialise
% add_libdir(path_concat(Jed_Home_Directory, "lib"));
%#v-
% will register the local and user-specific library-dir
This is used in /etc/jed.d/50jed-extra.sl in the jed-extra Debian
package.
I suppose I can use
#ifnexists add_libdir
() = evalfile("/FULL_PATH_TO/libdir.sl");
#endif
here.
2. A file providing more than one feature:
/usr/share/jed/jed-extra/drop-in/help.sl
% This help browser (with "hyperlinks") is a drop-in replacement for the
% standard help. Modes depending on extensions in this file should
% require("hyperhelp", "help.sl").
provide("help");
provide("hyperhelp");
This is used in two of my unpublished modes:
/home/milde/.jed/lib/configure.sl:34: require("hyperhelp", "help.sl");
/home/milde/.jed/lib/testscript-wizard.sl:12:require("hyperhelp", "help.sl");
Will I need a S-Lang version test and switch or is there another option
to solve these cases?
Or would you recommend use a different name for a modified file (even if
it provides a superset of features)?
Günter
More information about the Pkg-jed-devel
mailing list