Re: [PATCH v2 1/2] doc: add an option to have Asciidoctor build man pages directly

On 2021-05-14 at 19:53:13, Felipe Contreras wrote:

brian m. carlson wrote:

quoted

Asciidoctor contains a converter to generate man pages.  In some
environments, where building only the manual pages and not the other
documentation is desired, installing a toolchain for building
DocBook-based manual pages may be burdensome, and using Asciidoctor
directly may be easier, so let's add an option to build manual pages
using Asciidoctor without the DocBook toolchain.

We generally require Asciidoctor 1.5, but versions before 1.5.3 didn't
contain proper handling of the apostrophe, which is controlled normally
by the GNU_ROFF option.  This option for the DocBook toolchain, as well
as newer versions of Asciidoctor, makes groff output an ASCII apostrophe
instead of a Unicode apostrophe in text, so as to make copy and pasting
commands easier.  These newer versions of Asciidoctor (1.5.3 and above)
detect groff and do the right thing in all cases, so the GNU_ROFF option
is obsolete in this case.

I don't see what that paragraph has to do with the patch below.

It's relevant because it explains why it's acceptable to discount that
feature that we're not supporting as part of the patch.

quoted

We also need to update the code that tells Asciidoctor how to format our
linkgit macros so that it can output proper code for man pages.

Yes, but why shove it in this patch? Now this is is doing *two*
logically-independent changes.

This is one logical change: implementing Asciidoctor native support for
man pages.

quoted

Be careful to reset the font to the previous after the change.

This is a third change, since the current man pages already don't do
this:

  % zcat /usr/share/man/man1/git-add.1.gz | grep '\fB'
  you must use the \fBadd\fR command

As explained downthread, we don't know in the manual pages what font
styling we're in.  troff has font-change commands, not nesting begin-end
pairs, for italics and bold.  If the linkgit macro appears in the middle
of a passage in italics, by not using \fP, we'll force the rest of the
text which is to be italicized into roman.

The toolchain, whether Asciidoctor or the XSLT stylesheets, _does_ have
this context and therefore can explicitly move between bold and roman,
but our extensions do not.

quoted

We insert \e before each font-change backslash so Asciidoctor doesn't
convert them into \*(rs, the reverse solidus character, and instead
leaves them as we wanted them.

Right. So my patch was correct: it is neecessary.

Yes, I agree that it's necessary.  As I stated downthread, it appears my
branch was in a broken state.

quoted

Additionally, we don't want to use XML-style escapes for the litdd and
plus macros, so let's only use the XML-style escapes in HTML and XML and
use something different for our man pages.

That's a fourth change now, and one that complicates the Makefile even
more, when I've been trying to simplify it.

I'm sorry that this complicates work you'd like to do, but
unfortunately, the other option is broken rendering.

quoted

If users are using a more modern toolchain or don't care
about the rendering issues, they can enable the option.

What rendering issues?

They were mentioned upthread.

Also, the many should not suffer because of the few.

If a few people doing USE_ASCIIDOCTOR=YesPlease have issues (because of
ancient packages in their distribution, and their reluctance to type
`gem install`), then *they* can disable USE_ASCIIDOCTOR_MANPAGE (or just
disable USE_ASCIIDOCTOR altogether). Most people doing
USE_ASCIIDOCTOR=YesPlease should not suffer because of a
minority.

I don't believe we're going to agree on this.  I believe we should
choose defaults that work with the most popular Linux distributions, and
you don't.  I think your approach is unnecessarily hostile to ordinary
users and developers and understates the value that people derive from
distributions.

quoted

Signed-off-by: Felipe Contreras <redacted>

I most definitely do not sign off this.

This sign-off is not an approval of the patch.  This is the statement
that this patch is based on your work which is subject to the license
specified in the file and that you agreed that your original
contribution (now modified) could be distributed with your sign-off.  In
no portion of the DCO does it state that a sign-off means you think the
patch is a good idea or that you approve of it in any way.

I do want to be clear that I'm aware you don't approve of this patch and
that's why I submitted a counterproposal: because I don't approve of
your patch and you seem unwilling to make changes to it.  I would love
nothing more than to remove your name from it entirely, but
unfortunately, that's not possible with the DCO.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US