progress of jed-extra

[G. Milde]

On 25.11.05, Rafael Laboissiere wrote:
> * G. Milde <g.milde at web.de> [2005-11-25 15:42]:
 
> > Quite a lot of smaller fixes are done upstream, available at
> > http://jedmodes.sf.net/cvs/jedmodes-2.1.tgz
> 
> My first question: is the tarball above already official?

No, this is an unofficial pre-release from the web-space of Jedmodes.sf.net.

It is a moving target done for the ease of producing test versions of
jed-extra and feed back the resulting fixes into the upstream repository.

> What do you mean by "updating an upstream tarball"?  Do you release it
> with another version number?

No, the plan is to keep the number stable during the test phase so the scripts
do not need to be altered.  (the downside is that you cannot easily tell
the actual revision of http://jedmodes.sf.net/cvs/jedmodes-2.1.tgz short of
looking at the modification date)

Once jed-extra-2-1 passed all tests for release, I will make an official
release of jedmodes-2.1.tgz. The official release will use Sourceforge's
File Release System (FRS) and be announced and available for generic download
(under this name but another URL).


> > Shall we sort utils (scripts providing functions for other scripts)
> > into a separate libdir (jed-extra/utils/) and make autoloads for all
> > public functions there?
> 
> What would be the alternative option?

Leave as is: autoloads and add_completion() only for "end-user usable"
functions. All scripts that require/use other scripts ("utils") must ensure to
have the correct autoloads or require() statements.
    
  + small initialization script, keep status-quo
  - users that want to use funcions provided in the "utils" in their
    jed.rc or other homegrown scripts need to add autoloads.
  - some scripts in jed-extra need to be patched with autoloads.
  
Leave in one directory but make autoloads for all non-private functions
  
  - very long ini.sl file in JED_ROOT/jed-extra (> 700 autoloads)
  
Leave in one directory and add autoloads manually

  - lots of work  

 
> > Shall we include the "experimental and exotic" modes in the package, 
> > (e.g. in jed-extra/experimental/ and add a commented initializatin in
> > jed.d/50jed-extra.sl?
> 
> Why not?

Possible counter arguments are:

  * size of the package
  * more work in maintainging, e.g.
    incoming bug reports for stuff we know is experimental (maybe much of
    "wontfix" bugs)
  * a possibly wider audience for my experimental and "non-clean" scripts.
  
Despite of this, I am in favour of inclusion, as

  * the impact on the performance of jed is negligible
    (some more comment lines in 50jed-extra.sl)
  * people that have special needs or want to experiment have the scripts
    ready installed - no need to go to Jedmodes.sf.net.
  * with "experimental/" as a sub-dir of the added-to-path "jed-extra/",
    activation is dead easy, e.g. with 
      autoload("eX_mode", "experimental/eX.sl")
  * possible additional user feedback might stimulate the development and
    stabilization of the experimental modes.  


Guenter
    
    
  
  
  


-- 
G.Milde web.de