Re: [Texi2html-bug] Re: FSF assignment?

[Patrice Dumas]

On Mon, Oct 27, 2008 at 07:51:49PM -0400, Derek Price wrote:
> 
> Stuff from the current init files and command line is already stored in
> a package internally (Texi2HTML::Config), so it should be trivial to
> translate init files into submodules instead (Texi2HTML::Config::HTML,
> Texi2HTML::Config::Info, Texi2HTML::Config::DocBook, ...).  Then an
> arbitrary package that implements Texi2HTML::Config could be passed in
> as an argument to the main Texi2HTML package when loading the parser.
> 
> The texi2html.pl script could still create a Texi2HTML::Config package
> on the fly based on command line arguments as it does now, then pass
> that package to the Text2HTML package to configure it.

Ok. This looks good, as long as something like init files still work.
Maybe Thexi2HTML::THISDOC should also be handled like a normal package,
currently it is a hash. (and THIS_* should certainly be part of this
package).

> I would probably go a little further and enable multi-threading.  For
> that, the config package would need to be instantiated with new() and
> passed around as an object, like $config.  That is just a matter of
> initializing a hash via the package variables in new(), though, and also
> fairly simple to accomplish (in fact, it should be possible to implement
> this in a few lines in the parent Texi2HTML::Config package and ignore
> it in the specific configurations).  Then all current references like
> "Texi2HTML::Config::VARIABLE" would be replaced with
> "$config->{VARIABLE}", but that is also fairly straightforward and could
> probably be accomplished quickly with sed.

That could be doable. In fact this is more or less what I have done, to
be able to process more than one file (but I put the hash in
Texi2HTML::THISDOC):

* now config variables are read-only after command line switches
  expansion. If defined, they set $Texi2HTML::THISDOC{'VAR'}
  and if not defined, $Texi2HTML::THISDOC{'VAR'} is autodetected.
  $Texi2HTML::THISDOC{'VAR'} is then used in the code.


> Of course, with the new functionality and this packages new place in
> Texinfo, a Perl module name like Texinfo.pm (as opposed to Texi2HTML.pm)
> and the corresponding sub-namespaces might make more sense than the ones
> I suggested above.

Clearly.

> > That being said, it is the right time for a complete reorganization of
> > the interfaces toward something more modular. I think we can break
> > everything for the merge in texinfo (and I already have broken quite a
> > bit...).
> 
> How broken is it?  If it works now, I could make a quick pass at
> reorganizing as I just suggested, but I don't want to have to fix a
> bunch of stuff you are already working on in order to test my changes.
> For that matter, I don't want to start this work myself unless I know it
> can be released under the Artistic license.

I think that the best way to go would be: 

1. I finish what I have begun on the interface for new files. I am 
  motivated, so it should be done next week end.
2. I fix the 'little' bugs that were reported while I was doing some big
  changes. There aren't that much, this should be done also on the week
  end or next week.
3. You make a release.
4. you do all the changes you mentionned, and in parallel I work on the 
  makeinfo output since all the changes in the main program required to
  have makeinfo output should be done at that point.

--
Pat