Releases of jedmodes

[G. Milde]

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,
> 
> > * would you prefer|tolerate dpatches
> 
> > * 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. If
> often used modes that should be activated by default, use functions in
> utils/, then the files in utils/ will often be loaded, so if it's a
> problem to always load these, you have a problem anyway.

The problem is not so much the loading of files in utils/ but the
irreversibility of autoload commands. If jed.d/50jed-extra.sl loads
utils/ini.sl, the user has no choice but has to load these 150 lines of
autoloads which take up time and memory (except blocking all Debian
configuration with --skip-debian-setup).

Maybe this is acceptable, I am indifferent in this point. (Jörg?, Rafael?)


Thanks to Jörgs check_installation skript I could do some tests on
jed-extra-2.1.3:

With  

  append_libdir($1 + "utils/", 1);    % append and initialize 

in jed.d/50jed-extra.sl, there are no missing autoloads any more, while
with

  append_libdir($1 + "utils/", 0); 

several modes complain:

eXtra:  no bug in package, eXtra modes should be used with utils/ini.sl

drop-in:
  ispell_init.sl          push_defaults()
  hypermann.sl            string_nth_match()
  occur.sl                push_defautls()

utils:
  menutils		  push_defaults()

 
> My second preference would be a dpatch to the modes - that would be more
> work for the maintainer, but in general he would only need to check the
> location of the functions at the time of assembling the package - and
> looking at the dpatch currently in svn it doesn't look like a big deal.

The patch would need maintaining not only for the case the autoload file
arguments changes, but also for the case the patched modes is changed in a
way that the patches fail or lead to failure. This is why this would be the
last preferred version for me.

> My third preference would be adding some require() lines upstream rather
> than autoloads.

This looks like a possible compromise. 

* Could you add require("sl_utils") for ispell_init.sl and menutils.sl?

  sl_utils is the most basic utils file, so requiring it is not really a
  heavy thing.
  
  (Alternatively, we could require("sl_utils") in 50jed-extra.sl. However
  IMO it is bettere to make the dependency explicit in the upstream
  source, especially in menutils as this is an utility depending on
  utils...)
  
* hypermann.sl and occur.sl could IMO either be moved to eXtra or
  supplied with a require() --- whatever you prefer.


A different idea would be to provide a utils_autoloads.sl file (that we
can generate from the utils with make_ini.sl) both in Jedmodes and
jed-extra. This file should provide("utils_autoloads") and could be
require()d by all modes that assume autoloads for utils functions. 

This would 

* make the dependency transparent for the user 
  (no need to repeat the need to have these autoloads in every mode doc)
* keep the number of autoload() duplicates low 
* facilitate the moving of functions between *utils to
  allow optimal clustering.

What is your opinion? Should I present this idea in the jed-users list?


Günter

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