[Pkg-jed-commit] r59 - in trunk/packages/jed/debian: . init.d patches

[G. Milde]

On 14.09.05, Jörg Sommer wrote:
> G. Milde schrieb am Wed 14. Sep, 10:35 (+0200):
 
> > >   + added a function "register_libdir()", which *appends* a library
> > >   dir to the corresponding variables.
...
> > home-lib.sl has a function register_libdir() that *prepends* the path
> > for a reason. Drop-in replacements (e.g. Jedmodes' (hyper)help.sl) and
> > patched versions of standard library files should be found first by
> > evalfile() and friends also if they are provided by a package or the
> > sysadmin.
> 
> Indeed and I didn't find an aswer to this problem. 

How about two functions: add_libdir() and append_libdir() in
site-lib/home-lib.sl? (BTW, the mode should be renamed as well to match
its intention, maybe add_libdir.sl?)

> But I did this change, because I think installing a new package should
> not change the behaviour of the package. 

I agree that I do not like surprises after installing, say, spellutils.
However, installing jed-extra definitely should change the look and feel
of jed.

> And otherwise a new file 99home-jedrc.sl is needed to prepend the
> ~/.jed/ after all packages have prepended their dirs and if a package
> calls evalfile("foo") in its startup script this file can't get
> replaced by the user or sysadmin. 

I agree that the first two libs in jed_library_path should always be
Jed_Home_Lib and Jed_Local_Lib, so user or sysadmin could drop in their
replacements. Actually, to ensure this having jed.d/99local-libs.sl is a
sensible choice. (In jed.conf this adding occured after the evaluation of
jed-init.d.)

 
> > >   + it is also checked for ~/.jed and it is *prependened* in the
> > >     variables if it exist
> > 
> > If we leave register_libdir() as in home-lib.sl, it could be used
> > here, making the file a lot shorter.
> > 
> > IMHO, we should also register /usr/share/jed/site-lib/ so it is ready
> > for other packages to put their modes in.
> 
> I'm against placing files of different packages in the same directory.
> A new package should use (and register) a new directory to avoid name
> collision. And think of the problem of the compile-remove script.

I do not like the idea of registering a libdir for just one mode (and
a jed-library-path far too long to be visible in the minibuffer).

Furthermore, I like to see a "canonical" location for Debian-package
provided jed modes.

If e.g. a language package supplies a syntax highlighting mode foo.sl, it
should IMO suffice to place it in u/s/jed/site-lib/

If a non-jed package has more than one file for jed, it can place them in
a subdir of site-lib and use autoload("foo", "foo/foo") in the
initialization file.


..............

> > A function definition should IMO not be in a config file.
 
> A good question: Should jed-common ship more than what upstream provides?

The answer is yes, it already does (jed.d/, patches, README.debian).

> Or more strictly should jed-common include files of other parties than
> upstream and Debian?

No. However, as I am on pkg-jed-devel, home-lib.sl is Debian ;-).

..............

> > >   + now do not install jed.conf anymore and install the *.sl files in
> > >     /etc/jed.d/
> > 
> > /etc/jed.d/README.Debian-startup needs to be updated to this change.
> > (actually, this info should be in /u/s/doc/jed-common/README.debian.)
> 
> I thought about symlinking /e/j/RE... to /u/s/d/j/R... What do you think?

I'd place it in doc/jed-common/ and symlink to jed.d/.


> > > Added: trunk/packages/jed/debian/patches/40_site.sl-startup.dpatch
> > > ===================================================================
> > ...
> > > ++if (BATCH != 2) {  % do not evaluate if jed is started as jed-script
> > > ++    $1 = listdir("/etc/jed.d/");
> > ...
> > 
> > While this test will solve the "build a new jed version" problem, it is
> > IMHO not flexible enough.  What, if soemone wants to use jed-script with
> > a function provided by e.g. jed-extra?
> 
> Yes, I know. But introducing a new commandline option needs heavy changes
> on site.sl, because we must ignore this commandline option in
> command_line_hook(). 

I know, command_line_hook() is a mess. My first suggestion was an
environment variable. However, I think the best workaround is to use a
variable, say Skip_Debian_Init=0 and set it with the -f option

   jed-script -f Skip_Debian_Init=1 my_skript.sl

It seems like a good compromise to me. After all it is a rarely used
option, so ease of implementation/maintenance counts a lot. And it is
cleaner than an environment variable.

> Did we get a decision of name of the command line option?

Not a final one. The idea was to model it on emacs, but this would not be
possible with my above concept.


Guenter


-- 
G.Milde web.de