Re: Format inline code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/



[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux