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

[Jörg Sommer]

Hello G.,

G. Milde schrieb am Thu 15. Sep, 11:10 (+0200):
> On 14.09.05, Jörg Sommer wrote:
> > G. Milde schrieb am Wed 14. Sep, 10:35 (+0200):
>  
> > 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.

Why? I have the same problem with firefox. Debian provides many
extensions for it, but I can't install them, because the user can not
disable them, if they do not want them, and what's the big problem of
these extensions, they suck, they kill your cpu.

> > 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.)

But remember, we had the discussion about /many/ files in /etc/jed.d/ some
time ago. And the problem that a script in jed.d triggers a file
evaluation which can't get overwritten by the admin or the user still
extists.

> > > >   + 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).

Today, the jed library path is not visible in the minibuffer.

/home/joerg/.jed,/usr/local/share/jed/lib,/usr/share/jed/lib,/usr/share/jed/site-lib

It's IMO a impossible thing.

> > > > 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(). 

We learned on jed-users: No. It's simple. Provide an empty function named
as the command line option and all works. :)

> 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

This is not possible:

,----[ src/main.c ]---
|    script_file = NULL;
|    if (0 == strcmp (extract_file (argv[0]), "jed-script"))
|      {
|         Batch = 2;
|         SLang_Traceback = 1;
|         Jed_Load_Quietly = 1;
|         if (argc > 1)
|           script_file = argv[1];
|         else
|           {
|              script_usage ();
|              return -1;
|           }
|         argv++;                        /* make argv[0] the name of the script */
|         argc--;
|      }
`----

I think, jed-script should behave like slsh, i.e. not evaluate
/etc/jed.d/*, because a script has no way to prevent this and if someone
want to load jed.d before he can use jed -batch or evaluate it in its
script.

> > 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.

What about --skip-jed.d?

One question to you, Günther: Can you look through the patches and decide
which might be interesting for John and contact him? Or with other words
would take the role of the main contact person for upstream?

Bye, Jörg.
-- 
Das Recht, seine Meinung zu wechseln, ist eines der wichtigsten
menschlichen Previlegien.
	     		 			(Robert Peel)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-jed-devel/attachments/20050918/ca677a5e/attachment.pgp