public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: mtk.manpages@gmail.com,
	Alejandro Colomar <colomar.6.4.3@gmail.com>,
	linux-man <linux-man@vger.kernel.org>
Subject: Re: Format inline code
Date: Fri, 13 Nov 2020 11:11:08 +0100	[thread overview]
Message-ID: <a79fc055-c7ab-1793-04eb-eb4f678e5035@gmail.com> (raw)
In-Reply-To: <20201113094755.bg6pl7g2s5h2w4mu@localhost.localdomain>

On 11/13/20 10:47 AM, G. Branden Robinson wrote:
> At 2020-11-13T10:00:20+0100, Michael Kerrisk (man-pages) wrote:
>> But in the "-branden" version I see
>>
>> [[
>> .RS 6n
>> ]]
> 
> Yes.
> 
>> If I understand correctly, then that number is calculated based on the
>> ".IP * 2" that precedes it.
> 
> Yes.
> 
>> That doesn't seem good (since, maybe at some point, one might want to
>> change the .IP yo say ".IP  1) 3", and then one has to fix the .RS
>> lines. Am I missing something?
> 
> No.  This is why I don't have a solution for you yet.  The problem
> facing us is to set a code display (.EX/.EE) with the the following
> constraints.
> 
> A. It must be indented from its context by a predictable amount
>    irrespective of that context being an indented paragraph (.IP).
> B. Indented paragraphs must be free to use custom indentation amounts.
> C. The quantity of macro calls must be minimal.  (Probably 2: one to
>    commence the indenation and one to cancel it.)
> D. We want to use standard man(7) macros, not raw *roff requests.
> E. The solution should be portable to non-groff interpreters, ruling out
>    computation of indentation using internal variables specific to
>    groff's man(7) implementation to figure out the current indentation
>    amount.
> 
> So far I've only been able to come up with solutions if any one of (A),
> (B), or (C) is relaxed.
> 
> Please correct me if I've overstated of any of these constraints, or
> omitted one.

That seems a fair summary. I might add the following *preferences*
for a solution as well:

(f) Solution can be applied consistently throughout the corpus.
(g) Don't inject too much unneeded white space in the rendered
    output. (e.g. .TP/.RS/.RE forces a newline which may not 
    be desirable in all cases.

Our current solution relaxes constraint D (i.e., we use ".in").

It certainly looks like there's no way to solve the problem
without relaxing one of the constraint.

Thanks, as ever, for your input Branden.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

  reply	other threads:[~2020-11-13 10:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-05 10:19 Format inline code Alejandro Colomar
2020-11-05 11:36 ` Michael Kerrisk (man-pages)
2020-11-05 14:59   ` Alejandro Colomar
2020-11-05 21:37     ` Michael Kerrisk (man-pages)
2020-11-05 22:01       ` Alejandro Colomar
2020-11-06  9:38         ` Alejandro Colomar
2020-11-06 16:00           ` Michael Kerrisk (man-pages)
2020-11-06 16:36             ` Alejandro Colomar
2020-11-08 12:22               ` Michael Kerrisk (man-pages)
2020-11-12 11:32                 ` Alejandro Colomar
2020-11-12 21:17                 ` Alejandro Colomar
2020-11-13  8:28                   ` G. Branden Robinson
2020-11-13  9:00                     ` Michael Kerrisk (man-pages)
2020-11-13  9:47                       ` G. Branden Robinson
2020-11-13 10:11                         ` Michael Kerrisk (man-pages) [this message]
2020-11-13 10:21                       ` Alejandro Colomar
     [not found]                 ` <fbaf2a56-3f2e-e5ce-6ca2-e8f30156947d@gmail.com>
2020-11-12 21:20                   ` Alejandro Colomar
2020-11-12 22:55                     ` [RFC v1] perf_event_open.2: srcfix + ffix Alejandro Colomar
2020-11-13  9:21                       ` Michael Kerrisk (man-pages)
2020-11-13 10:26                         ` Alejandro Colomar
2020-11-13 10:39                           ` Michael Kerrisk (man-pages)

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=a79fc055-c7ab-1793-04eb-eb4f678e5035@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=colomar.6.4.3@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --cc=linux-man@vger.kernel.org \
    /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