update of jed-extra

[G. Milde]

On  6.07.05, Jörg Sommer wrote:
> G. Milde schrieb am Wed 06. Jul, 14:44 (+0200):
> > On  5.07.05, Jörg Sommer wrote:
> > > G. Milde schrieb am Tue 05. Jul, 15:36 (+0200):

> > > > * Should we use debconf to let the administrator decide which modes to
> > > >   activate/install?
> > > As a result of the discussion in debian-devel: No.
> > 
> > Well, is there a "sensible default"?
> > 
> > I see two ways of activating: 
> >   
> >    * the admin copies files to Jed_Local_Library and activates manually
> >      (e.g. by running make_ini()). The mode is then out of Debian control
> >      and will not be updated nor removed by apt-get.
> >      
> >      Bad.
> >      
> >    * In something that is not debconf, the admin tells jed-extra which
> >      modes to activate. 
> 
>      * the admin can set _Jed_Default_Emualtion in jed.conf to the one he
>        wants.
> 
> >      So why not in debconf?
> 
> Because it's simple easy to edit jed.conf or do we talk about
> different things?

Yes, I got your point regarding the _Jed_Default_Emualtion an already
changed jed.conf accordingly.

Here we have a different problem: Which jed-extra modes should be
activated?


Alternatively to the exclusion_list now in make_ini, we could introduce a
"whitelist" of modes to generate autoloads or INITIALIZATION blocks in
ini.sl. 

  * This "whitelist" would be configurable via debconf (with sensible 
    defaults to be agreed on) and medium, ..., low priority.
    
    This way the sysadmin could control the activation via
    dpkg-reconfigure jed-extra while the modes stay under Debian
    control.
  
  * It should be a comma-separated string, so that it can be extended by
    files in jed-init.d/ provided by other packages.
    
  * make_ini's list_slang_files will use this whitelist, if it is
    defined.
    
  * Every libdir should have (or not have) its own whitelist. How about
    an Assoc_Type[String_Type, ""] with the libdirs path as key?


---------------------

> > > Can the user do anything if it don't want a mode after we have
> > > enabled it?
 
> > The non-root user can only overwrite functions and variables in .jedrc,
> >     --> not really nice.
> 
> ACK. 

So we should make sure, only modes that "do not do nasty things" are
activated.

 * The simplest case are modes that just provide functions - they
   should not stand in the way.
   
   Also, modes like numbuf or navigate are easy: placing them in the
   library-path is ok, as they are activated by a require() in ~/.jedrc
   (or if the sysadmin decides to have them for all, in jed.conf). 
   
 * Arguable cases are modes like ch_table, that use ini.sl to insert a
   new menu item.

 * Also, drop-in replacements like (hyper)help and (hyper)man, recent,
   ispell, brief, cua need a carefull consideration. However, most of
   them are backwards compatible, to activating is not too problematic.
   However, they can pose problems for users of alternative alternatives.

 * Rather exotic or experimental modes could be kept in
   u/s/doc/jed-extra/exapmles
 
> A way would be to disable loading of jed.conf with command line option.

This is the "brute force" option, as it disables all other
configurations. 

However, with carefully chosen/patched modes the problems should only
occure for the experienced user that either is also an administrator or
able to copy (and modify) jed.conf to the start of his|her .jedrc, so it
should work (and be documented) as a last resort.


> We should patch site.sl.

... and send this patch to John as well. Or even better ask John,
as the command_line_hook is a really convoluted piece of code.

BTW: Emacs calls this option --no-site-file, as our configuration file is
called jed.conf (and not running site.sl is a rather bad idea), I would
like to call the corresponding jed argument --no-conf-file.


Günter

-- 
G.Milde web.de