update of jed-extra
G. Milde
g.milde@web.de
Thu Jul 7 07:38:04 UTC 2005
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
More information about the Pkg-jed-devel
mailing list