Re: [Groff] inconsistent synopsis for .MAILTO

[Ted Harding]

On 04-Jan-02 Ralph Corderoy wrote:
> 
> Hi Werner,
> 
>> Overloading *might* work.  More important is consistency -- if I have
>> a line-oriented macro foo, it's easy to remember that, say, <foo and
>> foo> start and end the block-oriented versions.
> 
> As an aside, I'd vote against the < and > characters personally.  A S
> and E suffix as in PS/PE, TS/TE, etc., would be fine.  <> just look
> wrong in a troff macro name.

While I agree that they "just look wrong" (all old-timers
probably do agree about this!), this doesn't make it
obvious that they're undesirable.

As an example at the other extreme, I once had what
amounted to an XML-like source document (data for a
dictionary) where each new entry was introduced by
<HWORD> and there were other similar tags for different
sections of the entry, each at the start of a line.

Stage 1 was to run this through a 'sed' script which
replaced each such "<TAG>" by ".<TAG>".

Stage 2 was to write a set of macros on the lines of

  .de <TAG>
  xxxxxxxxx
  ..

to do appropriate formatting. Nothing whatever undesirable
about the presence of "<" and ">" here! Similarly, one
can also use

  .<TAG>
  yyyyyyyyy
  .</TAG>

in order to retain maximum visual compatibility with
markups like XML and HTML -- even though, in pure groff
terms, there's some unnecessary typing required here,
which would be alleviated by

  .TAG
  yyyyyyyyy
  ./TAG

(which is actually slightly more economical than
".<TAG .... .TAG>" or ".TAGS" .... ".TAGE").

That being said, I do retain some doubt about the
proposed convention

  .<TAG
  zzzzzzzzz
  .TAG>

which my "intuition" hasn't quite adapted to, and which
I'm not convinced there's a need for.

Frankly, you can call the opening macro what you like and
the corresponding closing macro whetever else you like;
groff will cope. As Ralph point out, there is a long-
standing ".TAGS" ... ".TAGE" groff convention (by no
means fully adhered to, by the way -- compare ".B1"
and ".B2" to begin and end boxed text). We could also
have the HTML-type convention ".<TAG>" .... ".</TAG>"
or ".TAG" .... "./TAG", which has the advantage of
conforming to an already widely used convention.

Does it help to put yet another convention into the
arena?

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 167 1972
Date: 06-Jan-02                                       Time: 08:55:58
------------------------------ XFMail ------------------------------