Re: [Groff] Progress report on the portability audit -- and what to do about URLs?

[Larry Kollar]

Eric S. Raymond wrote:

> .... Many groff pages use the www.tmac macros
> .URL and .MTO.  This opens up a significant can of worms because the
> www.tmac code is unsalvageable, full of constructions that cannot be
> made viewer-portable.  Thus, any page using these will either break
> some viewers entirely or at best display in a somewhat mangled form.
>
> I would have caught this sooner, but doclifter just ignores the
> www.tmac include and interprets .URL and MTO itself.  Therefore it
> doesn't have a problem, and if I were only trying to solve doclifter's
> issues I could declare victory and go home.
>
> We have several possible paths to go from here:
>
> (1) Rewrite www.tmac in portable code (no groff extensions).  This
>    could work because most third-party viewers do follow .so  
> directives.

If possible, that would be best. As you said, it may not be a realistic
alternative -- especially if you include long request/macro names in
"no groff extensions."

> (2) Add portable implementations of .URL and .MTO to an-old.tmac

That would be OK. I'd like to see at least the list constructs (OLS,  
ULS,
DLS) added as well. I don't think any of the current manpages use
them, but they should be encouraged.

> (3) Restore the .UR and .UE macros that used to exist in
>    at least in the Linux version of the man macros.  I can't find the
>    documentation for these any more, but I remember reading it and
>    support for it is in doclifter; what happened to this feature?

Never heard of them... are they used anywhere? I would argue
against it myself; we have URL and it's not going anywhere. :-)

> (4) Rip out the MTO and URL macros entirely, and trust Web-aware  
> viewers
>    to pick out URLs and mail addresses by pattern recognition.  Some,
>    including doclifter, already do this.

Urk. Sounds like a step backwards.

> I need a quick decision about this, because it will affect the set  
> of cleanup
> patches I turn in.

Of the feasible choices, I would pick (2).

--
Larry Kollar     k  o  l  l  a  r  @  a  l  l  t  e  l  .  n  e  t
Unix Text Processing: "UTP Revival"
http://unixtext.org/