.RS

.RS

[Alejandro Colomar (man-pages)]

Hi,

We already talked about something similar some time ago.

I see [.RS 4] and [.RS +4n] used in the man pages.
And there are also [.in +4n] and I think I've also seen [.in 4].
Is there any difference between [+4n] and a simple [4]?
Which is the preferred one?

And BTW, does [.RS] do anything different than [.in]?

I guess the code implementing those macros is written somewhere.
Where can I have a look at that code to see it myself?

Thanks,

Alex

Re: .RS

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 5568 bytes --]

Hi Alex!

And hi to Michael, too.  I'm sorry I haven't responded to your pings
about a good idiom for inset code examples.  The main reason is that I
don't yet have one that satisfies all of your criteria.  The other is
that groff is heaving its vast bulk toward a release, and I've been in a
perfectionist frenzy trying to clear my plate of my personal release
goals for it.  This includes man pages totalling 323 pages (not counting
groff_mdoc(7)[1]), which might not sound all that daunting to the author
of the scale-tipping _LPMI_ codex.  :D

At 2020-11-11T15:22:27+0100, Alejandro Colomar (man-pages) wrote:
> Hi,
> 
> We already talked about something similar some time ago.
> 
> I see [.RS 4] and [.RS +4n] used in the man pages.
> And there are also [.in +4n] and I think I've also seen [.in 4].
> Is there any difference between [+4n] and a simple [4]?

Not usually.  *roff parameters can be dimensionless (like hyphenation
modes), but many of them, like page length, line length, page offset,
indent(ation), and many others, have dimensions.  groff, like AT&T troff
before it, supports the expression of dimensions in a variety of units,
including U.S. traditional, metric, and printer's units (points, picas).
Ultimately, internally, all these different units are converted to
"basic units" which are meaningless outside of the formatter (but you
sometimes see them in diagnostic messages).

So when you use a request or a built-in register that has a dimension
associated with it, you need to either know what units are required to
get predictable output, or _tell_ *roff what units you want to use.
The way you do that is with a letter called a "scaling indicator".

These are documented.  See the section "NUMERICAL EXPRESSIONS"[2] in
groff(7) for a complete list.

Requests and (some) registers have a "default scaling indicator".  These
are document with the corresponding item.

"n" refers to "ens", a typographer's unit that is, roughly half an "em",
and an "em" is the width of a lowercase "m" in the current font.  For
character-cell terminals, 1m equals 1n equals 1 character cell, so it's
pretty easy to get a handle on.

> Which is the preferred one?

That's a terrific question.  I've wavered on this issue myself.
Semantically, there is no difference between ".RS" (or ".in") "4" and
"4n"--because the default scaling indicator for this macro (or request)
is "n".

At present I kind of lean toward "4n" because I think it disserves man
page authors to get too far away from the knowledge that groff is a
_typesetting_ system as troff and nroff (and roff, and Saltzer's RUNOFF)
were before it.

If man pages were only ever rendered to character-cell terminals[3], I'd
probably just settle on ignoring scaling indicators.  In fact, I'm not
sure they existed in *roff languages before Ossanna wrote troff.  As I
understand it, on Teletypes and line printers, your horizontal dimension
was character cells, your vertical dimension was lines, and you had
special logic for reverse line feeds and half line feeds in either
direction, and that was as granular as things got.

> And BTW, does [.RS] do anything different than [.in]?

At its core, no--but it saves a lot of state so that you can nest
further .RS calls, and use .RE, and so that the sectioning macros (.SH
and .SS) can undo their effect without causing havoc.

> I guess the code implementing those macros is written somewhere.
> Where can I have a look at that code to see it myself?

Here's the bleeding edge version:

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/an-old.tmac

There is almost certainly a copy of this file, probably from groff
1.22.4 on your system.  On my Debian box, it's at
/usr/share/groff/1.22.4/tmac/an-old.tmac.

Thomas Dickey once complained about the lack of comments in this
file--he's right, the things that a casual user most needs commented,
are not.  I've tried to remedy that defect in groff_man(7), but a more
Doxygenish approach to the package source itself would also be a good
idea.

Regards,
Branden

[1] groff_mdoc(7) will _ship_, but a person _really_ doesn't want to
know why it's not in my page count.  Ask me if you want a challenge
involving possibly diversions and traps.

[2] In groff 1.23.0, to no longer be in shouty capitals.  :D

[3] I sometimes get into a bit of conflict with some man page writers
who care less than nothing for any output device that isn't a terminal.
I want to accommodate such people as much as I can without compromising
quality for those who want to want to see man pages properly typeset.

The most recent episode of contretemps involves the sad history of
ASCII, ISO 8859, Unicode, and how exactly ' and ` (and to a lesser
extent, ^ and ~) should be rendered.  Some painful choices were made in
the 1970s, and some procrastination was coddled in the 2000s, that have
people grumbling today.  People threaten that the masses will just "go
to Markdown" if ignorance is not coddled.  For people who really care
_only_ about terminal input, I'm not sure such an out-migration can be
stopped, or should be.  Proper typesetting carries a lot of complexity
and it's hard to justify that complexity to people who don't want what
it can accomplish.

About the only challenge Markdown faces is filling, and I'm sure there
are tools to handle that it in its much simpler problem domain.  That,
or people just resize or horizontally scroll their terminals.  The
mindset is a bit foreign to me.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: .RS

[Alejandro Colomar (man-pages)]

Thanks, Branden!

And [+4n] is because you can also indent negatively?
But I guess I can omit [+] safely always.

Thanks,

Alex

On 11/11/20 4:09 PM, G. Branden Robinson wrote:
> Hi Alex!
> 
> And hi to Michael, too.  I'm sorry I haven't responded to your pings
> about a good idiom for inset code examples.  The main reason is that I
> don't yet have one that satisfies all of your criteria.  The other is
> that groff is heaving its vast bulk toward a release, and I've been in a
> perfectionist frenzy trying to clear my plate of my personal release
> goals for it.  This includes man pages totalling 323 pages (not counting
> groff_mdoc(7)[1]), which might not sound all that daunting to the author
> of the scale-tipping _LPMI_ codex.  :D
> 
> At 2020-11-11T15:22:27+0100, Alejandro Colomar (man-pages) wrote:
>> Hi,
>>
>> We already talked about something similar some time ago.
>>
>> I see [.RS 4] and [.RS +4n] used in the man pages.
>> And there are also [.in +4n] and I think I've also seen [.in 4].
>> Is there any difference between [+4n] and a simple [4]?
> 
> Not usually.  *roff parameters can be dimensionless (like hyphenation
> modes), but many of them, like page length, line length, page offset,
> indent(ation), and many others, have dimensions.  groff, like AT&T troff
> before it, supports the expression of dimensions in a variety of units,
> including U.S. traditional, metric, and printer's units (points, picas).
> Ultimately, internally, all these different units are converted to
> "basic units" which are meaningless outside of the formatter (but you
> sometimes see them in diagnostic messages).
> 
> So when you use a request or a built-in register that has a dimension
> associated with it, you need to either know what units are required to
> get predictable output, or _tell_ *roff what units you want to use.
> The way you do that is with a letter called a "scaling indicator".
> 
> These are documented.  See the section "NUMERICAL EXPRESSIONS"[2] in
> groff(7) for a complete list.
> 
> Requests and (some) registers have a "default scaling indicator".  These
> are document with the corresponding item.
> 
> "n" refers to "ens", a typographer's unit that is, roughly half an "em",
> and an "em" is the width of a lowercase "m" in the current font.  For
> character-cell terminals, 1m equals 1n equals 1 character cell, so it's
> pretty easy to get a handle on.
> 
>> Which is the preferred one?
> 
> That's a terrific question.  I've wavered on this issue myself.
> Semantically, there is no difference between ".RS" (or ".in") "4" and
> "4n"--because the default scaling indicator for this macro (or request)
> is "n".
> 
> At present I kind of lean toward "4n" because I think it disserves man
> page authors to get too far away from the knowledge that groff is a
> _typesetting_ system as troff and nroff (and roff, and Saltzer's RUNOFF)
> were before it.
> 
> If man pages were only ever rendered to character-cell terminals[3], I'd
> probably just settle on ignoring scaling indicators.  In fact, I'm not
> sure they existed in *roff languages before Ossanna wrote troff.  As I
> understand it, on Teletypes and line printers, your horizontal dimension
> was character cells, your vertical dimension was lines, and you had
> special logic for reverse line feeds and half line feeds in either
> direction, and that was as granular as things got.
> 
>> And BTW, does [.RS] do anything different than [.in]?
> 
> At its core, no--but it saves a lot of state so that you can nest
> further .RS calls, and use .RE, and so that the sectioning macros (.SH
> and .SS) can undo their effect without causing havoc.
> 
>> I guess the code implementing those macros is written somewhere.
>> Where can I have a look at that code to see it myself?
> 
> Here's the bleeding edge version:
> 
> https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/an-old.tmac
> 
> There is almost certainly a copy of this file, probably from groff
> 1.22.4 on your system.  On my Debian box, it's at
> /usr/share/groff/1.22.4/tmac/an-old.tmac.
> 
> Thomas Dickey once complained about the lack of comments in this
> file--he's right, the things that a casual user most needs commented,
> are not.  I've tried to remedy that defect in groff_man(7), but a more
> Doxygenish approach to the package source itself would also be a good
> idea.
> 
> Regards,
> Branden
> 
> [1] groff_mdoc(7) will _ship_, but a person _really_ doesn't want to
> know why it's not in my page count.  Ask me if you want a challenge
> involving possibly diversions and traps.
> 
> [2] In groff 1.23.0, to no longer be in shouty capitals.  :D
> 
> [3] I sometimes get into a bit of conflict with some man page writers
> who care less than nothing for any output device that isn't a terminal.
> I want to accommodate such people as much as I can without compromising
> quality for those who want to want to see man pages properly typeset.
> 
> The most recent episode of contretemps involves the sad history of
> ASCII, ISO 8859, Unicode, and how exactly ' and ` (and to a lesser
> extent, ^ and ~) should be rendered.  Some painful choices were made in
> the 1970s, and some procrastination was coddled in the 2000s, that have
> people grumbling today.  People threaten that the masses will just "go
> to Markdown" if ignorance is not coddled.  For people who really care
> _only_ about terminal input, I'm not sure such an out-migration can be
> stopped, or should be.  Proper typesetting carries a lot of complexity
> and it's hard to justify that complexity to people who don't want what
> it can accomplish.
> 
> About the only challenge Markdown faces is filling, and I'm sure there
> are tools to handle that it in its much simpler problem domain.  That,
> or people just resize or horizontally scroll their terminals.  The
> mindset is a bit foreign to me.
> 

Re: .RS

[G. Branden Robinson]

[-- Attachment #1.1: Type: text/plain, Size: 2688 bytes --]

At 2020-11-11T16:34:15+0100, Alejandro Colomar (man-pages) wrote:
> Thanks, Branden!
> 
> And [+4n] is because you can also indent negatively?
> But I guess I can omit [+] safely always.

Yes.  The unary plus is redundant for both .RS and .in.  I see it used
much more frequently with .in requests, though.  I think it has to do
with the greater awareness of formatter state one has to maintain when
writing in "raw" roff requests.  People include the plus as a form of
documentation.

You can indent negatively, and even to an absolute horizontal page
position (with the '|' prefix).  I don't see this done in real world
man pages and I sure don't encourage it before the question of how well
non-roff man page renderers (like mandoc) handle it.

Here's how RS is defined in V7 Unix's tmac.an:

' # increase relative indent
.de RS
.nr ]\\n+()p \\n()I
.nr )\\n()p \\n()R
.ie !"\\$1"" .nr )R +\\$1n
.el .nr )R +\\n()I
.nr )I .5i
.}E
..

And here's groff's definition of the same macro, which hasn't changed in
20 years[2].

.de1 RS
.  nr an-saved-margin\\n[an-level] \\n[an-margin]
.  nr an-saved-prevailing-indent\\n[an-level] \\n[an-prevailing-indent]
.  ie \\n[.$] .nr an-margin +(n;\\$1)
.  el         .nr an-margin +\\n[an-prevailing-indent]
.  in \\n[an-margin]u
.  nr an-prevailing-indent \\n[IN]
.  nr an-level +1
..

The leading plus sign when the macro argument $1 is interpolated ensures
that if the caller doesn't supply a sign, the value will be interpreted
as an increment when updating the register value.  This is part of
general register management syntax rather than anything to do with
indentations or page formatting.

An example with very simple register settings may help elucidate this.

$ nroff
.nr A 2
.nr B 3
.nr A +5
.nr B 5
.tm \nA
7
.tm \nB
5

(I'm sort of making nroff work like a REPL here--an underrated approach
to learning it, in my opinion.  I typed the requests, and nroff [really
groff] wrote the "7" and "5" to standard error.)

The interesting thing to me is that .RS in V7 doesn't do any indentation
itself; instead it uses registers a bit differently.  And the register
names are limited to a two-character name length.

For the attached document I get identical output[3] from groff and
Heirloom Doctools troff, which is a direct descendant of the AT&T
implementation.

Regards,
Branden

[1] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/lib/tmac/tmac.an
[2] 19 years for the very first line, because groff introduced the 'de1'
    request at that time.
[3] modulus groff's use of SGR escapes instead of overstriking to
    achieve bold output; see grotty(1).

[-- Attachment #1.2: RS-negative.man --]
[-- Type: application/x-troff-man, Size: 270 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: .RS

[Alejandro Colomar (man-pages)]

Thanks again, Branden!

Cheers,

Alex

Re: .RS

[Alejandro Colomar (man-pages)]

Hi Branden and Michael,

Okay, after some testing:

* [.in 4] simply doesn't seem to work at all.
* [.RS 4] and [.RS +4n] seem to be equivalent.
* [.RS 4] is different (worse) than [.in +4n]
          in some very specific scenario:

[[
.IP * 2
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
nisi ut aliquip ex ea commodo consequat.
.\""""""""""""""""""""""""""""""""""""""""""
.IP		\" Indent is 2n after this
.in +4n		\" Indent is 6n after this
.EX
I am indented 6n from normal paragraphs.
.EE
.in		\" Return to normal
.\"""""""""""""""""""""""""""""""""""""""""""
.IP *
Augue interdum velit euismod in pellentesque.
Tristique senectus et netus et malesuada fames ac turpis egestas.
Gravida arcu ac tortor dignissim convallis.
.\"""""""""""""""""""""""""""""""""""""""""""
.IP		\" Indent is 2n after this
.RS 4		\" Indent is _4n_ after this
.EX
I am indented 4n from normal paragraphs!!!
.EE
.RE		\" Return to normal
.\"""""""""""""""""""""""""""""""""""""""""""
]]

This happens in perf_event_open.2,
where [.in +4n] is used,
and when I changed it to [.RS/.RE] I saw this change in behavior.

Do you know why is that?

Thanks,

Alex

Re: .RS

[Alejandro Colomar (man-pages)]

> * [.in 4] simply doesn't seem to work at all.
> * [.RS 4] and [.RS +4n] seem to be equivalent.
> * [.RS 4] is different (worse) than [.in +4n]
>           in some very specific scenario:
> 
and [.in 4n] seems to indent to absolute column 4.

Re: .RS

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

At 2020-11-12T21:57:34+0100, Alejandro Colomar (man-pages) wrote:
> > * [.in 4] simply doesn't seem to work at all.

It's important here to check what request comes next.  Many of the man
macros will change the indentation again on you.

> > * [.RS 4] and [.RS +4n] seem to be equivalent.
> > * [.RS 4] is different (worse) than [.in +4n]
> >           in some very specific scenario:
> > 
> and [.in 4n] seems to indent to absolute column 4.

Yes.  Many *roff requests are documented like .in is in groff(7).

   .in ±N    Change indentation according to ±N (default scaling indica‐
             tor m).

The ± indicates an optional sign.  Where there is no sign, the .in
request performs absolute positioning.  I might have led you astray by
bringing up the "|" operator before; a hazard of my unfortunate tendency
to ramble when composing emails in haste.

The '+' that .RS forces as a prefix to its argument before passing it to
.in prevents the _macro_ argument from being interpreted as an absolute
position (even if the "|" operator is used).

.TH foo 1 2020-11-13 "foo 1.2.3"
.SH Name
bar \- baz
.SH Description
foo
.RS 4n
indent
.RS |5n
bar
.RE
.RE

In the above example, "bar" is set 5 ens to the right of "foo", even
though we tried to set it much farther left.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: .RS

[Michael Kerrisk (man-pages)]

On 11/12/20 8:57 PM, Alejandro Colomar (man-pages) wrote:
> Hi Branden and Michael,
> 
> Okay, after some testing:
> 
> * [.in 4] simply doesn't seem to work at all.
> * [.RS 4] and [.RS +4n] seem to be equivalent.
> * [.RS 4] is different (worse) than [.in +4n]
>           in some very specific scenario:
> 
> [[
> .IP * 2
> Lorem ipsum dolor sit amet, consectetur adipiscing elit,
> sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
> Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
> nisi ut aliquip ex ea commodo consequat.
> .\""""""""""""""""""""""""""""""""""""""""""
> .IP		\" Indent is 2n after this
> .in +4n		\" Indent is 6n after this
> .EX
> I am indented 6n from normal paragraphs.
> .EE
> .in		\" Return to normal
> .\"""""""""""""""""""""""""""""""""""""""""""
> .IP *
> Augue interdum velit euismod in pellentesque.
> Tristique senectus et netus et malesuada fames ac turpis egestas.
> Gravida arcu ac tortor dignissim convallis.
> .\"""""""""""""""""""""""""""""""""""""""""""
> .IP		\" Indent is 2n after this
> .RS 4		\" Indent is _4n_ after this
> .EX
> I am indented 4n from normal paragraphs!!!
> .EE
> .RE		\" Return to normal
> .\"""""""""""""""""""""""""""""""""""""""""""
> ]]
> 
> This happens in perf_event_open.2,
> where [.in +4n] is used,
> and when I changed it to [.RS/.RE] I saw this change in behavior.
> 
> Do you know why is that?

Hmmm -- I don't know. I was going to ask, doesn't s/>RS 4/.RS +4n/
fix the problem? But I see that it does not.

By the way, your comments (\") actually cause the rendered
output to change, as far as I can see! In particular,
the \" on the final .RE leads to some strangeness:

[[
.IP * 2
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
nisi ut aliquip ex ea commodo consequat.
.\""""""""""""""""""""""""""""""""""""""""""
.IP             \" Indent is 2n after this
.in +4n         \" Indent is 6n after this
.EX
I am indented 6n from normal paragraphs.
.EE
.in             \" Return to normal
.\"""""""""""""""""""""""""""""""""""""""""""
.IP *
Augue interdum velit euismod in pellentesque.
Tristique senectus et netus et malesuada fames ac turpis egestas.
Gravida arcu ac tortor dignissim convallis.
.\"""""""""""""""""""""""""""""""""""""""""""
.IP             \" Indent is 2n after this
.RS 4
.EX
I am indented 4n from normal paragraphs!!!
.EE
.RE             \" nom
.\"""""""""""""""""""""""""""""""""""""""""""
.PP
Augue interdum velit euismod in pellentesque.
]]

Gives:

[[
       * Lorem  ipsum dolor sit amet, consectetur adipiscing elit, sed do
         eiusmod tempor incididunt ut labore et dolore magna aliqua.   Ut
         enim  ad minim veniam, quis nostrud exercitation ullamco laboris
         nisi ut aliquip ex ea commodo consequat.

             I am indented 6n from normal paragraphs.

       * Augue interdum velit euismod in pellentesque.  Tristique  senec‐
         tus et netus et malesuada fames ac turpis egestas.  Gravida arcu
         ac tortor dignissim convallis.

           I am indented 4n from normal paragraphs!!!

Augue interdum velit euismod in pellentesque.
]]

No indent at all on the final line!

Thanks,

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

Re: .RS

[Michael Kerrisk (man-pages)]

Hi Branden,

On 11/13/20 10:38 AM, G. Branden Robinson wrote:
> At 2020-11-13T09:52:06+0100, Michael Kerrisk (man-pages) wrote:
>> Hmmm -- I don't know. I was going to ask, doesn't s/>RS 4/.RS +4n/
>> fix the problem? But I see that it does not.
> 
> No, these should be synonymous.
> 
>> By the way, your comments (\") actually cause the rendered
>> output to change, as far as I can see! In particular,
>> the \" on the final .RE leads to some strangeness:
> 
> I can't reproduce that, apply Alex's changes as I understand them to the
> actual man page from Git.
> 
> I'm attaching 3 versions.  The stock page, the "Alex" approach, and the
> "Branden" approach, each tweaks only the indentation of these code
> examples in the 2-cell-indented, starrred paragraphs, and adds a C
> comment to the example to make it easy to distinguish them, since it's a
> long page and the footer is far away.
> 
>> No indent at all on the final line!
> 
> That certainly seems bizarre based on the "lorem ipsum" stuff I saw.  I
> think this may have been a patch-application error.

Hmmmm - I can't now reproduce, so I guess you are right. My bad, sorry.

> Here are my observations on the 3 attached versions.  My comparison
> method was to give each page its own maximized terminal window, "man -l"
> it, then forward-search in less(1) to "Reading results", and
> Alt+backtick in my window manager to flip between the versions.
> 
> The surrounding context of all these examples is an .IP paragraph, so
> the stock solution, and Alex's, are using .IP inside .IP.  This is not
> discouraged in man(7); it just needs to be noted.
> 
> stock:   The code example is indented 6 cells from the asterisk in its
>          parent paragraph.  Uses .IP/.in/.EX/.../.EE/.in.
> 
> alex:    The code example is indented 4 cells from the asterisk in its
>          parent paragraph.  This is because of the semantics of .RS;
>          its inset is offset from a _normal_ (.PP) paragraph, not an
>          indented one.  It's my understanding that this is compatible
>          with man(7) semantics all the way back to 1979, but it is has
>          a source of frustration to me, you, and others, and that is why
>          I have documented it so carefully in groff_man(7) and
>          groff_man_style(7).  Uses .IP/.RS 4/.EX/.../.EE/.RE.
> 
> branden: The code example is indented 2 cells from the asterisk in its
>          parent pargraph.  This may not be desirable, but on the bright
>          side the preceding .RS call has no argument.  You could use
>          another .RS/.RE pair to get further indentation, but that has
>          the undesirable properties of increasing line count and of not
>          being robust to relocation outside of an indented paragraph.
>          Uses .RS/.PP/.EX/.../.EE/.RE.

But I want the code samples to be indented 4 cells from the paragraph 
left margin (i.e., 6 cells from the asterisk in this case). So I prefer
"stock" (status quo). The semantics of .RS are indeed unfortunate.

Thanks,

Michael

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

Re: .RS

[Alejandro Colomar]

Hi Michael,

On 11/13/20 9:52 AM, Michael Kerrisk (man-pages) wrote:
[...]
>> Do you know why is that?
> 
> Hmmm -- I don't know. I was going to ask, doesn't s/>RS 4/.RS +4n/
> fix the problem? But I see that it does not.

No; I tried many things, but I didn't find a solution.
So, we'll have to keep using .in, right?

> 
> By the way, your comments (\") actually cause the rendered
> output to change, as far as I can see! In particular,
> the \" on the final .RE leads to some strangeness:
> 
> [[
> .IP * 2
> Lorem ipsum dolor sit amet, consectetur adipiscing elit,
> sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
> Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
> nisi ut aliquip ex ea commodo consequat.
> .\""""""""""""""""""""""""""""""""""""""""""
> .IP             \" Indent is 2n after this
> .in +4n         \" Indent is 6n after this
> .EX
> I am indented 6n from normal paragraphs.
> .EE
> .in             \" Return to normal
> .\"""""""""""""""""""""""""""""""""""""""""""
> .IP *
> Augue interdum velit euismod in pellentesque.
> Tristique senectus et netus et malesuada fames ac turpis egestas.
> Gravida arcu ac tortor dignissim convallis.
> .\"""""""""""""""""""""""""""""""""""""""""""
> .IP             \" Indent is 2n after this
> .RS 4
> .EX
> I am indented 4n from normal paragraphs!!!
> .EE
> .RE             \" nom
> .\"""""""""""""""""""""""""""""""""""""""""""
> .PP
> Augue interdum velit euismod in pellentesque.
> ]]
> 
> Gives:
> 
> [[
>        * Lorem  ipsum dolor sit amet, consectetur adipiscing elit, sed do
>          eiusmod tempor incididunt ut labore et dolore magna aliqua.   Ut
>          enim  ad minim veniam, quis nostrud exercitation ullamco laboris
>          nisi ut aliquip ex ea commodo consequat.
> 
>              I am indented 6n from normal paragraphs.
> 
>        * Augue interdum velit euismod in pellentesque.  Tristique  senec‐
>          tus et netus et malesuada fames ac turpis egestas.  Gravida arcu
>          ac tortor dignissim convallis.
> 
>            I am indented 4n from normal paragraphs!!!
> 
> Augue interdum velit euismod in pellentesque.
> ]]
> 
> No indent at all on the final line!

Hmm that's weird.  I added the comments in the email, so I didn't test them.

Thanks,

Alex

Re: .RS

[Michael Kerrisk (man-pages)]

Hi ALex,

On 11/13/20 11:15 AM, Alejandro Colomar wrote:
> 
> Hi Michael,
> 
> On 11/13/20 9:52 AM, Michael Kerrisk (man-pages) wrote:
> [...]
>>> Do you know why is that?
>>
>> Hmmm -- I don't know. I was going to ask, doesn't s/>RS 4/.RS +4n/
>> fix the problem? But I see that it does not.
> 
> No; I tried many things, but I didn't find a solution.
> So, we'll have to keep using .in, right?

It looks that way to me.

>> By the way, your comments (\") actually cause the rendered
>> output to change, as far as I can see! In particular,
>> the \" on the final .RE leads to some strangeness:
>>
>> [[
>> .IP * 2
>> Lorem ipsum dolor sit amet, consectetur adipiscing elit,
>> sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
>> Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
>> nisi ut aliquip ex ea commodo consequat.
>> .\""""""""""""""""""""""""""""""""""""""""""
>> .IP             \" Indent is 2n after this
>> .in +4n         \" Indent is 6n after this
>> .EX
>> I am indented 6n from normal paragraphs.
>> .EE
>> .in             \" Return to normal
>> .\"""""""""""""""""""""""""""""""""""""""""""
>> .IP *
>> Augue interdum velit euismod in pellentesque.
>> Tristique senectus et netus et malesuada fames ac turpis egestas.
>> Gravida arcu ac tortor dignissim convallis.
>> .\"""""""""""""""""""""""""""""""""""""""""""
>> .IP             \" Indent is 2n after this
>> .RS 4
>> .EX
>> I am indented 4n from normal paragraphs!!!
>> .EE
>> .RE             \" nom
>> .\"""""""""""""""""""""""""""""""""""""""""""
>> .PP
>> Augue interdum velit euismod in pellentesque.
>> ]]
>>
>> Gives:
>>
>> [[
>>        * Lorem  ipsum dolor sit amet, consectetur adipiscing elit, sed do
>>          eiusmod tempor incididunt ut labore et dolore magna aliqua.   Ut
>>          enim  ad minim veniam, quis nostrud exercitation ullamco laboris
>>          nisi ut aliquip ex ea commodo consequat.
>>
>>              I am indented 6n from normal paragraphs.
>>
>>        * Augue interdum velit euismod in pellentesque.  Tristique  senec‐
>>          tus et netus et malesuada fames ac turpis egestas.  Gravida arcu
>>          ac tortor dignissim convallis.
>>
>>            I am indented 4n from normal paragraphs!!!
>>
>> Augue interdum velit euismod in pellentesque.
>> ]]
>>
>> No indent at all on the final line!
> 
> Hmm that's weird.  I added the comments in the email, so I didn't test them.

Branden could not reproduce, and now I can't either. So I must have
messed up. Ignore my comments please.

Thanks,

Michael

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

Re: .RS

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

[sent to list only]

At 2020-11-12T18:09:15+1100, G. Branden Robinson wrote:
> Yes.  The unary plus is redundant for both .RS and .in.

The above is a half-truth.  The unary plus is redundant for .RS, but not
for .in.  I corrected myself as part of later discussion but I didn't
want to let this error go without a clear and obvious corrigendum.

This stuff is confusiong enough without me adding to it!

My apologies.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]