[Top][All Lists]
[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
- [Texi2html-bug] process init files after all the command lines,
Patrice Dumas <=