Releases of jedmodes

[G. Milde]

On 29.05.06, Jörg Sommer wrote:
> G. Milde schrieb am Mon 29. May, 11:24 (+0200):
> > On 27.05.06, Jörg Sommer wrote:
> > > Paul Boekholt schrieb am Sat 27. May, 12:41 (+0200):

 
> > Currently my compromise is:
> > 
> > * modes in jed-extra/, jed-extra/utils and jed-extra/drop-in are
> >   self-contained, i.e. define the needed autoload() and requires() to
> >   run without additional configuration.
> 
> What do you mean with ???self-contain???? 

"define the needed autoload() and requires() to run without additional
configuration"

> For example, cal.sl (a drop-in mode) misses a requires() for keydefs.
> Can you create a dpatch?

I would report the problem to the mode's creator and ask to fix this.

If the author doesnot respond or thinks that this is not a bug in his/her
mode, I'd ask at jedmodes-users at lists.sourceforge.net if the mode is orphaned
and if someone can fix it.

To fix jed-extra, there are several options:

 * move the mode to jed-extra/extra/ (if the mode is orphaned or rarely
   used)

 * provide a commented dpatch (if the mode is heavily used or other modes
   depend on it) The comment should contain the problem and the reason
   why this is fixed in a dpatch and not upstream.

 
> > * Modes that either
> >   
> >   - need additional configuration steps
> 
> What are ???additional configuration steps????

Anything a user needs to write into his/her jed.rc (or a sysadmin in a
/etc/jed.d file), e.g. keybindings, menu additions, variable settings,
requirements.

These steps are usually described in the header of the modes source. 

> I saw some modes (rfcview come into my mind) they need some proper
> configuration, e.g. setting some custom variables. Debian provides the
> RFCs in the packages doc-rfc*. I intend to make such configurations (e.g.
> patch the mode or what else is needed) to make them easier usable for
> Debian users.

You refer to the case where a mode author doesnot know e.g. a path but
the jed-extra packager does (as we know the system is Debian)?

Also in this case, my first step would be to get in contact with the
author and report the problem or enhancement suggestion. Maybe there is
a way to provide this path (or whatever it is) as a default in the
unpatched source.

Even if this is not the case, I would generally prefer an example or
documentation over a dpatch, as this would also help if the user replaces
the mode in question by a new version from Jedmodes in his/her jed home
library.

Any remaining changes to the modes due to dpatches need to be documented
in the README.Debian, so that the user has a chance to find out why a
mode that worked without additional configuration doesnot work any more
when a new version from Jedmodes is used.

> > I.e. IMO 
> > 
> >   * there is no need for a missing autoloads() patch for modes in
> >     jed-extra/extra.
> 
> Right, but if it is done it's a goody for our user. 

IMO, we should assume, that eXtra modes require the evaluation
of jed-extra/utils/ini.sl. The examples document this and provide the code.

Can you really guarantee the maintaining of all these autoloads for the
future? I fully agree with Paul on:

> > > > the autoload would itself become
> > > > a bug if the autoloaded function moves to another file.

even if I prefer included autoloads in basic modes.

 
> >   * missing autoloads() in the "basic" modes are to be fixed, either
> >     upstream (my preference)
> 
> But upstream refuses this. 
>
> As Paul said ???Missing autoloads are not a bug ...

Paul is just one of several upstream authors.


> >     or, by creating (and maintaining!) a dpatch.
> 
> I don't see this as a big problem.

I do. I do not believe I can spend as much time as currently on the
jed-extra package in the future. And I do believe that an undocumented or
an outdated patch is worse than no patch at all.


Günter