[bug #62726] [me] intro manual: clarify available user namespace

[G. Branden Robinson]

Follow-up Comment #3, bug #62726 (project groff):

[comment #2 comment #2:]
> [comment #1 comment #1:]
> > I have for quite a while been contemplating _removing_ the
> > auto-load of the _www_ macro package from the macro file for
> > the _html_ output device, however.
> 
> OK, I may as well wait and see where you land on that bigger issue before
spending any more time on this minuscule one.

It is of course possible to use the HTML output device as a kind of weird
terminal, or a somewhat dumb typesetter.  One of the things I want to do is
clearly establish what those capabilities are.

> Regardless of whether the www macros are autoloaded, it sure seems like any
document wanting to take any real advantage of HTML functionality--hyperlinks
being the most basic and obvious example--will require them.

Not true!

Consider two practical examples recently demonstrated.

With man pages (both man(7) and mdoc(7)) we have hyperlink support both for
PDF and terminal output devices.

As recently shown with my re-typesetting of Kernighan & Cherry's eqn user's
guide, with a ONE-LINE patch to K&C's private `SC` sectioning macro, we have
clickable links to sections in the navigation pane.  Under the original
definition of a hyperlink as I understand it, text you can poke your finger on
to "go" to the referenced material is exactly what this is.

Internet URLs do demand specialized support.  man(7) and mdoc(7) already have
macros to support those and do so in HTML, PDF, and terminal output; they
don't need to load the 'www' package to get it.

The means of access to this type of feature is the device control command, and
the recognition of such commands by the output driver program is where the
magic really happens.

Consequently people can put hyperlinks to Internet URLs in their me(7)
documents _today_.  The downside is that they have to input \X escape
sequences to do it, and this seems to scare most *roff users (they did me
backed when I signed on to join this navy).

I speculate that www.tmac was originally conceived as a supplementary macro
package for _any_ full-service package.  But the advent of mandoc and its
community's insistence on a greatly reduced subsetting of the input language
for the sake of portability (and concealment of mandoc's own limitations) has
already taken man pages out of www.tmac's application domain.

I wonder if perhaps it would be better for other full-service packages to just
go ahead and add extension macros for the features they want.  In some cases
even that isn't necessary: as seen with the porting of K&C's paper to
gropdf(1), if a work title or author name is well-behaved input-wise, it can
be shoved into document metadata verbatim.

Having a stronger `troff` request to sanitize any diversion, string, or macro
of node data is a feature that I am increasingly coming to think is both
feasible and desirable.  Think, instead of "asciify", "utf8ify".  Anything
that can be back-converted to ASCII or a UTF-8 sequence (not forgetting that
our old friends the hyphen-minus, caret, tilde, etc. are _not ASCII_ unless
remapped) is, and everything else is thrown out.

I relatedly think that arguments to the `tm` family of requests (including
`ab`) should be similarly handled.  I think it would be significant effort for
little benefit to add general localization support for troff output to the
standard error stream.  That is, I don't want troff to have to care whether
the environment uses Latin-1 or Latin-9 or Unicode.  So the argument(s) to
these requests would be scooped into a temporary anonymous troff string and
then "utf8-sanitized" as described above, then re-emitted.   As a first cut I
wouldn't even inspect the environment, but just blast out the bytes in UTF-8
and if somebody's terminal encoding ain't that, they get mojibake.

I seem to have wandered onto the topic of Debian #906091
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906091>...

>  Still, forcing the user to explicitly specify this macro package means the
only users who do so will be ones _using_ macros from it, so they should know
what macros it defines and be able to avoid those.

I think this is the more polite thing to do, to avoid such a squat on the
available portable name space.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62726>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/