texi2html-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texi2html-bug] process init files after all the command lines


From: Patrice Dumas
Subject: [Texi2html-bug] process init files after all the command lines
Date: Sun, 24 May 2009 01:56:13 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hello,

The formats can now be loaded dynamically with --xml, --html, --info 
and so on.

Currently, when those selectors are mixed with user init files, 
formats override the user changes and overrides one another leading 
to messed up output, with some things overriden by the next option, 
and other inherited from previous init files or formats.

For example

makeinfo.pl --info --split=chapter -init myfile.init --xml

leads to, in that order:

 info.init loaded
 SPLIT=chapter
 myfile.init loaded
 xml.init loaded

which leads to a mess, with some things formatted like info, others 
like xml, when xml.init overrides what comes from info.init, 
with non-predictable messing in-between in myfile.init, some changes
being overriden for sure in xml.init (lke the SPLIT from commandline) 
other being inherited from myfile.init.


So I'd like to change the processing of command line options and
init files to have something simpler and more predictable avoiding
multiple format loading and having command line options taking
precedence in most cases except when they conflict with the 
format. What I propose is more precisely:

1. Defaults are set (from texi2html.init).

2. Configuration files are loaded.

3. Command line processing:
 * command line options that sets defaults, like --footnote-style=..
   are taken into account when they appear on the command line, and set 
   a default for the whole run (in general, it means that they use 
   set_conf(.,.,1) and the coresponding variable is accessed through 
   get_conf(.) and never directly), and they are not overwritten
   by changes in init files and formats (except when using 
   set_conf(.,.,1) in an init file, this could be needed when 
   something set on the command line doesn't makes sense for the
   output format, like split and --plaintext).

 * format selection options are not processed when they arrive, 
   they are only collected, and are discarded except the last one,
   which is the default format.

 * init files are collected as they arrive but not loaded.

4. the default format is loaded. If there is no format selected, 
   default is html when called as texi2html, info if called as 
   makeinfo and raw text if called otherwise.

5. the init files are loaded. Formats called like init files are 
   also loaded at that point. (for example -init docbook.init is 
   processed here, while --docbook would have been loaded in 4.).


It means that init files can override what was set before, including
lead to wrong combinations, but I don't think we should care. Being
sure which format is loaded and having thte init files able to
override the format is right, in my opinion. In any case, in most
cases, an init file tailored for an output format won't work for 
another output format.


Does it look right?

--
Pat




reply via email to

[Prev in Thread] Current Thread [Next in Thread]