[EMAIL PROTECTED] writes:
> features and quite a few style-files hadn't been rewritten. I haven't
> done anything on it since, but some ideas from l2h-ng have gone into l2h.
> Unless someone else expends efforts into bringing l2h-ng up-to-date it will
> probably never stand on its own.
So, it's dead. Too bad; it sounds like the right approach.
> > I noticed that you are getting $_ passed in, and then performing a
> > destructive operation on it; should $_ be removed from the interface
...
> was possible that one would want to read an argument from a piece of text
> that had previously been read. For example, a `$' invokes a read up to the
Hm, I could see using a "stream-identifier" parameter, and then
support explicit stream creation via an additional function. On the
other hand, if that's not used, it's a lot of overhead. So dropping
it might be a better idea, or having separate interfaces for specified
stream and the default stream.
> > major boon (due to simplicity of the interface), but would have to be
> > supported in the dispatcher. Is this done in l2h-ng, and are there
> > plans for including this feature in l2h 98.x?
>
> This was one of the major features of l2h-ng and it would take a big
> boatload of work to include it in l2h. You see, one of the biggest
> problems of l2h is that everything is processed "inside-out". That is,
> the innermost environment is processed first. In l2h-ng processing occurs
I was thinking, at this point, of simply having the
get_next_argument() function knowing whether an environment was being
processed or not; getting the sequence right is clearly a much bigger
task. In particular, a global variable could be set to "env" just
before do_env_*() is called, and to "cmd" just before do_cmd_*() is
called. This would allow get_next_argument() to "get it right,"
avoiding a lot of the pain associated argument extraction. The most
difficult part is finding all the places such an assignment would need
to be made; less difficult for someone familiar with the structure of
the sources and Perl syntax than for me.
> in standard TeX order. This is done by treating environments exactly like
...
> LaTeX. For example, an environment can be opened in one file and closed in
It also means I could do the indexing the way I want to! (Or at
least the same way I do in LaTeX.) *THAT* is a big issue for me.
> another. Major minus: You have to make exactly sure that you handle all the
> nesting levels right. Otherwise things can go very bad.
But it sounds like this is dealt with entirely by the do_cmd_begin()
and do_cmd_end() functions; why would this be a problem?
-Fred
--
Fred L. Drake, Jr.
[EMAIL PROTECTED]
Corporation for National Research Initiatives
1895 Preston White Drive Reston, VA 20191
