git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin Ågren" <martin.agren@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Git Mailing List <git@vger.kernel.org>,
	"brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH] manpage-bold-literal.xsl: provide namespaced template for "d:literal"
Date: Thu, 31 Oct 2019 07:19:30 +0100	[thread overview]
Message-ID: <CAN0heSrWqc2cyqOBVaWQOJHs4+48viAGL7YPGP6QnDrf+m_Jpw@mail.gmail.com> (raw)
In-Reply-To: <20191030212422.GE29013@sigill.intra.peff.net>

On Wed, 30 Oct 2019 at 22:24, Jeff King <peff@peff.net> wrote:
>
> On Wed, Oct 30, 2019 at 09:41:04PM +0100, Martin Ågren wrote:
>
> > We recently regressed our rendering of "literal" elements in our
> > manpages, i.e, stuff we have placed within `backticks` in order to
> > render as monospace. In particular, we lost the bold rendering of such
> > literal text.
>
> This is just when rendering with asciidoctor, right? AFAICT the bolding
> is still fine in pages built with asciidoc.

Right. Sorry for being unclear. Fixed in v2.

> > One reason this was not caught in review is that our doc-diff tool diffs
> > without any boldness, i.e., it "only" compares text.
>
> I don't think this was intentional, but just a consequence of
> redirecting man's stdout to a non-terminal. Doing:
>
>   MAN_KEEP_FORMATTING=1 ./doc-diff --asciidoctor HEAD^ HEAD
>
> on your patch shows the improvement, though note that the diffed version
> is kind of ugly. It looks like the bolding is done with ^H characters,
> and it interacts in a funny way with our diff coloring, as well as with
> diff-highlight if you use it. Piping the above through "less" looks
> decent, but it gives me pause on whether we should be setting that
> variable inside the script.

Very interesting! Thanks for this trick.

> Speaking of annoyances, is it just me, or does the rendering stage of
> doc-diff not actually proceed in parallel? Doing this seems to help, but
> I'm not sure why:
>
> diff --git a/Documentation/doc-diff b/Documentation/doc-diff
> index 88a9b20168..1694300e50 100755
> --- a/Documentation/doc-diff
> +++ b/Documentation/doc-diff
> @@ -127,7 +127,7 @@ generate_render_makefile () {
>         while read src
>         do
>                 dst=$2/${src#$1/}
> -               printf 'all:: %s\n' "$dst"
> +               printf 'all: %s\n' "$dst"
>                 printf '%s: %s\n' "$dst" "$src"
>                 printf '\t@echo >&2 "  RENDER $(notdir $@)" && \\\n'
>                 printf '\tmkdir -p $(dir $@) && \\\n'
>

Hm, didn't look into this. Will try to find the time.

> I also confirmed with the MAN_KEEP_FORMATTING trick above that "doc-diff
> --asciidoctor" fixes the problem as advertised, and "--asciidoc" has no
> change at all.

Thanks!

> >  There are more manpage-*.xsl -- manpage-suppress-sp.xsl looks like it
> >  would have the exact same problem. But before diving in too deep, I'd
> >  rather submit this one to see if it's in the right direction at all.
>
> It looks like a lot of them don't actually match on the namespaced
> tagnames, and so are OK. Some of them require special options to enable,
> so we wouldn't necessarily notice problems via doc-diff.
>
> From my brief look, I think suppress-sp is the only one that needs
> attention. I kind of wonder if we can just drop it. According to the
> Makefile comment, it's needed only for docbook 1.69.1-1.71.0. But 1.71.1
> came out in 2006. Surely even RHEL7 or whatever ancient system people
> use is past that, right? :)

I also only had a brief look and realized I wouldn't know how to test
with such a broken version, so I didn't feel comfortable mucking around
with that file.

> Or alternatively, as I've argued elsewhere, we could simply be a little
> more aggressive about deprecating old doc build tools. According to the
> Makefile, no extra settings are needed with docbook >1.73.0. That came
> out in 2007. I'd be willing to just call that the cutoff point, and
> anybody without it can install the pre-formatted pages.

Yeah, that makes sense.

Martin

  reply	other threads:[~2019-10-31  6:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30 20:41 [PATCH] manpage-bold-literal.xsl: provide namespaced template for "d:literal" Martin Ågren
2019-10-30 21:24 ` Jeff King
2019-10-31  6:19   ` Martin Ågren [this message]
2019-10-31  2:31 ` brian m. carlson
2019-10-31  6:21   ` Martin Ågren
2019-11-02  5:45     ` Junio C Hamano
2019-10-31  6:22 ` [PATCH v2] manpage-bold-literal.xsl: match for namespaced "d:literal" in template Martin Ågren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN0heSrWqc2cyqOBVaWQOJHs4+48viAGL7YPGP6QnDrf+m_Jpw@mail.gmail.com \
    --to=martin.agren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).