Larry Kollar wrote: > Chuck, did you see my response on 9 Dec? > http://lists.gnu.org/archive/html/groff/2009-12/msg00008.html > > One way or another, you have to get an HTML list wrapper to appear in the > output, that should give you the break you need.
No, I hadn't seen that, it occurred (apparently) just hours before I subscribed to the list. I appreciate the code below, but to be honest, I feel relatively confident that I can write my macro code (either from my head, or more likely stealing good ideas from existing macro packages), it was trying to find the basic strategy that bothered me. I can see several different methods to solve my problems, and I wanted to get hints as to things more of the "where to do it" than the "how to do it". I got mail from Werner, who was nice enough to give me several important points. First, yes, I will now send everything thru the list. Second, he tells me that his opinion is that instead of me worrying about trying to repair his macros (which was my first impulse, to fix them, and then add calls to them in a little adapter macro package), I should instead try to see if I can fit my fixes all directly into the mm macros. Normally at this point, I'd go ask Joergen Haegg (author of the mm macros) for his permission & comments, but he'd told me back when I was hunting for some way to talk to the html authors, that he hadn't any more time for groff matters, and that this list is now the sole point of contact for everyone. So, consider this a notification that I'm planning to offer a set of diffs for the mm macros. I know, until you folks see the diffs, you couldn't possibly give me an OK, but that's the general path I'm after. Another thing ... the general form of the html markup is that sections must be explicitly opened and closed, unlike things like the LI request. Because of this, I need to be able to keep track, in a stack-like data structure, of both the currently active list structure, and if a list item is currently open. I haven't figured out exactly how to implement a stack-like structure in groff code, I've seen one way, but it seems *really* messy/klugy, so I want to check on it first. Anyhow, the rest of my strategy will be not to implement the .LB basic lists at all, instead, to intercept AL, BL, ML, and VL, and the concommitant LI or DD items, and do the html stuff inside there. Trying to handle stuff inside LB would be just too difficult to handle. As far as the macros renaming Larry demonstrated for me, it seems to me that if I've detected that I'm using -Thtml, then I don't really have any need to rename, I can actually *remove* the old list macros and replace them bodily with html versions. The only thing that bothered me was a matter of order; I wanted to actually have read in the mm macros before I deleted and replaced them, but if my fixes now have to actually go into the same file (the m.tmac?) then I guess I can control order myself. I was just not anxious to do this for testings sake. And I will honor Werner's request, I won't modify or use the www.tmac stuff (although that was exactly what I'd been thinking to do).
