Releases of jedmodes

[G. Milde]

On  4.06.06, Jörg Sommer wrote:
> Hallo G.,
> G. Milde schrieb am Thu 01. Jun, 15:06 (+0200):
> > On 31.05.06, Paul Boekholt wrote:
> > > On Wed, 31 May 2006 16:32:10 +0200, "G. Milde" <g.milde at web.de> said:
> > > 
> > > > Paul, for often used modes that should be activated by default in a
> > > > Debian system with jed-extra installed:
> > > 
> > > > * would you agree to add autoloads to the original source,
> 
> I would prefer this. 


> From your point of view as jedmodes maintainer I would force to use
> autoload(), because this way you could do a automatic dependency
> checking and provide the user with the information of the needed
> dependencies, for example.

1. As Paul is a Jedmodes maintainer as well, there is no way I can
   force a policy on him.

2. Dependency checking needs to be done by the creator before the
   upload and the dependencies are to be listed in the modes meta data
   file (dcdata.txt). They will appear in the modes home page
   (jedmodes.sf.net/mode/<modename>/).
   
   BTW: as these dcdata.txt files contain useful information about the
   modes, we could consider putting them in doc/jed-extra/mode-docs/
 
3. While for the Jedmodes repository inconsistencies and different ways
   of satisfying dependencies are a feature rather than a bug, the
   jed-extra package needs this checking and a common approach.
   
   However documenting that you need to load jed-extra/utils/ini.sl
   in order to use modes in jed-extra/extra/ is IMO all right.


> And I think a missing autoload() is a sign of an unclean mode. 

Not necessarily. If it is a documented step in the mode initialisation,
putting an autoload() or require("utils/ini.sl") in jed.rc is not
essentially different from putting require("<modename>") there or add a
menu init hook.

> Is there one mode in the jed/lib that is based on the assumption the
> user loads a different mode before? I don't know of one.

This is a different piece of cake. There is also no mode in the Jed distro
that assumes you to extend the jed-library path.  jed/lib has all the
autoloads in site.sl. Non-standard extensions need additional
configuration. Whether the author decides to put autoload() in every
single mode or to collect them in one place is not a question of clean or
not but of practicability and personal taste.
 
> Another point is, it breakes any automatism and prevents tools like
> fetch_mode_from_jedmodes().

If I am going to write it, fetch_mode_from_jedmodes() will rely on the
mode metadata under jedmodes.sf.net/mode/<modename>/dcdata.txt providing
the requirements.

> > > > * would you prefer|insist on loading the autoloads via utils/ini.sl in 
> > > >   jed.d/50jed-extra.sl
> > > 
> > > My first preference would be for utils/ini.sl to be loaded by default.
> 
> I remember one year ago both of you talked totally different: I've
> proposed to load different files of configuration upon startup. That
> were your opinions:
> 
> ,----[ G. Milde ]---
> | 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.
> `----
> 
> ,----[ Paul Boekholt ]---
> | This could become quite slow.  On my system, GNU Emacs starts much faster
> | than Xemacs, because Xemacs has to load a .elc file for every extension
> | package, and GNU Emacs does not (I'm not sure how GNU Emacs does it).
> `----
> 
> Now we talk about this again. The names of the files changed and the
> place where they are, but the core is the same. And one thing seems
> different: you proposed it.

I can understand your problem. However, optimisation is always complex
and non-linear.  There is a trade-off between ease of use, startup time,
and complexity and maintability. The central autoload() file will make
maintaining easier for the mode author(s).


utils/ini.sl is not a configuration file in the way
jed.d/* files or jed.rc is. It is more like site.sl - residing in the
jed-library path rather than in a config dir, not intended for hand
editing. Additionally, utils/ini.sl is auto-generated (and hence it is
not so easy to move its contents to a proper config file).


But for fast load-up, minimal invasiveness and maximal transparency, I
would propose a new alternative:

 If Paul cannot be convinced to add require() or autoload() to the no-X
 modes, these autoloads should be added to jed.d/50jed-extra.sl
 (instead of dpatches)
 
IMO, 

 * this is the place where a sysadmin will look first (or second),
 * it avoids surprises if a dpatched mode is superseded by a new version 
   from Jedmodes by a user,
 * it is significantly less startup code than evaluating utils/ini.sl by
   default,
 * it is even less code than adding the autoloads to the individual
   modes ;-)  
 
Günter


-- 
Milde ife.et.tu-dresden.de