Hi,
Bernd Warken wrote on Sat, Jan 04, 2014 at 07:23:42PM +0000:
> commit 309660d6de892de92c9b4b89c160cb4e4606736b
> Author: Bernd Warken <groff-bernd.warken...@web.de>
> Date: Sat Jan 4 20:21:05 2014 +0100
>
> Add request .FONT to an-ext.tmac.
I consider this a very, very bad idea for multiple reasons
and kindly ask that it be reverted, completely.
The man(7) language is legacy and should not be used for writing
new manuals. We have both mdoc(7) and various other systems for
writing new manuals.
The only three remaining points why man(7) is still important are
(1) to support old systems not having mdoc(7), using an automatic
mdoc(7) to man(7) converter (like mandoc -Tman) and
(2) to support prepocessors like pod2man(1) and
(3) for historical purposes, for example to demonstrate the
behaviour of historical UNIX manual formatting or to format
historical manuals. For example, i use it regularly to
format pre-4.4BSD (e.g. 3BSD or v7 AT&T UNIX) manuals.
None of these profit from new features, quite to the contrary.
It is hard to see how one could do more harm than by adding new
features to a language almost exclusively kept for compatibility.
Besides, this is violating the spirit and the the syntax conventions
of the man(7) language. The man(7) language uses two-character
macro names, and old implementations may depend on that. It also
violates the spirit because there are no other macros requiring -
or even supporting - long argument lists or operations of this
complexity. With traditional roff implementations, that is not
even possible, given the argument limit. The other man-ext macros
(today i would already call those legacy, too) can be copied into
individual manuals for portabilty - that's ugly, but at least it
works. With your .FONT macro, that won't even work due to the
argument limit.
The implementation is sloppy.
What if the document at hand uses \*[result],
just to name one example?
Given the other problems, i refrained from a more thorough audit.
Finally, the functionality you propose is completely pointless.
For common cases, we already have .RB etc.
For unusual cases,
.ft B
bold text
.ft R
followed by normal text
.ft I
followed by italic text
.ft P
or even
\fBbold\fRnormal\fIitalic\fP
is perfectly fine.
> Put under GPL2 and reorder groff_man.man.
You are not the author.
Why do you think you are allowed to change the license?
To not waste more time, i'm not checking the reordering right now,
but given the rest of this commit, i must say i'm not convinced
it makes sense.
> 2013-01-02 Deri James <d...@chuzzlewit.myzen.co.uk>
>
> * src/devices/gropdf/gropdf.pl: gropdf use to fail when handling
> - output from preconv, now works.
> + output from preconv, now works.
It looks like you broke the ChangeLog as well.
Yours,
Ingo
