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

[G. Milde]

On 18.09.05, Jörg Sommer wrote:
> 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.

Well, we have some way to go untill jed will use as much cpu (or memory) as
firefox ;-)

Apart from that, I do not think that *appending* a library-dir is the
solution. We need a way to let the user choice which extensions|modes
should be activated. In case of drop-in replacements, this is easier if
we let the user add or append the libdir.
 
> > > 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. 

Yes, many (not preparsed) files slowing down the startup. 

If this becomes a problem, I envisage a more elaborated startup
mechanism: A function to merge all *.sl files and preparse the result (a
bit like update-modules does with modprobe.d/). If there is no newer file
in jed.d, load the preparsed "meta-file" at startup, else proceed as
today.

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

You cannot get rid of this, as long as packages are allowed to put
something into jed.d/. You can only make sure to explain your policy to
packagers (and an admin can modify all files in etc/jed.d/ as these are
config files, finding the culprit is more of a problem).

However, with the prepending of ~/.jed/lib in 95local-libs.sl, file
evaluation by jed.d/ skripts will use the standard versions. I am not
sure whether this is now good or bad.


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

On my box it is:

          /home/milde/.jed/lib,/usr/share/jed/lib,.

But the point was: keep it as short as sensibly possible.

 
> > > > > Added: trunk/packages/jed/debian/patches/40_site.sl-startup.dpatch
> > > > > ===================================================================

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

If I got it right, jed-script doesnot take any command line options, so
that `jed-script --skip-jed-d some-skript.sl` would not work?

In this case, you are right to skip the jed.d/ evaluation.

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

This will not work, as you cannot have a function called skip_jed.d().

So, maybe (in order of preference)

          jed --skip-init-d
          jed --skip-jed-d
          jed --skip-init
	  jed --skip-debian-init


I would ask you to implement the change, as I am not firm on dpatches.
(If, OTOH the startup were defined in defaults.sl, I could esily do it.)


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

I'll try my best. Unfortunately, I have a thesis to finish...

Guenter


-- 
G.Milde web.de