bug 219448

[G. Milde]

On  1.05.05, Jörg Sommer wrote:
> [Cc-ing John, maybe he can help.]
> 
> Hello,
> 
> this bug [1] is really interesting. 

(subject is "please allow /etc/jed-init.d/ to override global settings",
 IMHO, this is easier to understand than bug 219448)

> The problem is this:
> please allow /etc/jed-init.d/ to override global settings
> $ xjed -batch
> loading /usr/share/jed/lib/site.slc
> loading /usr/share/jed/lib/os.sl
> loading /usr/share/jed/lib/menus.slc
> loading /etc/jed.conf
> 
> Here a admin may make system wide setting
> 
> loading /etc/jed-init.d/00debian.sl

Or here, in any file that resides in /etc/jed-init.d/ as all these will
be loaded at every startup.

> loading /usr/share/jed/lib/jed.rc
> 
> and here they get overwritten by jeds default settings.

(If and only if the user doesn't have a ~/.jedrc file.)

> /etc/jed.conf become loaded at the end of site.sl. jed.rc become loaded
> by the command line hook, which is called after site.sl has quit. This
> must change, we can't make system wide settings before program defaults.

Maybe we could persuade John to renounce the "catchall" loading of
JED_ROOT/lib/jed.rc as this is clearly not "the right way" to provide
defaults.

Maybe one could abandon the complete Default_Jedrc_Startup_File custom
variable and load mechanism. 

The only difference of "site administrator customisation" I see between
using

   defaults.sl or jed.conf
vs
   setting Default_Jedrc_Startup_File and providing this file

is the possibility to disable the Default_Jedrc_Startup_File with the -n
command line option. (However, this disables the users jedrc too.)
But maybe I am missing something here.   
 
 
> I would say, we should remove /usr/share/jed/lib/jed.rc 

I would not remove JED_ROOT/lib/jed.rc, as the original jed documentation
refers to it as a reference (a la "copy ... to ~/.jedrc and adapt to your
needs...").

> and put it at the beginning of /etc/jed.conf 

This should not be necessary, as JED_ROOT/lib/jed.rc just reflects the
default settings. AFAIK, early versions of jed depended on some variable
definitions done in jed.rc (or .jedrc) but this is solved since some time
now. (And `jed -n` should give errors at some stage otherwise.)

> and set Default_Jedrc_Startup_File to NULL to prevent jed.rc is
> searched by command_line_hook().

This will suffice. 

 
> Does anyone know, why a command_line_hook is necessary? 

To make things more complicated? ;-)

Well, it allows the user (in .jedrc) or the site-administrator to
overwrite the command_line_hook. (Unfortunately, that this hook is
quite long.)

My filelist.sl documents an example use of this feature:

%   Problem: Currently, a relative filename is expanded before passing 
%   it to the _jed_find_file_before_hooks, with the side-effect of 
%   "http://host.domain" becoming "/host.domain"
%   -> find_file doesn't work for URIs with a double slash
%
%   If you want to be able to start jed with e.g.
%      jed http://jedmodes.sf.net/mode/uri/
%   you can copy the 194 lines of the command_line_hook from site.sl 
%   to your .jedrc and modify the 6.-last line from
%     () = find_file (next_file_arg);
%   to
%     () = find_uri (next_file_arg);



-- 
G.Milde web.de