groff
[Top][All Lists]
Advanced

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

Re: .ss paragraph-style-footnote example, then and now


From: Dave Kemper
Subject: Re: .ss paragraph-style-footnote example, then and now
Date: Sat, 03 Apr 2021 04:23:22 -0500

Hi Branden,

I too need to amend misstatements in my original post.  Unfortunately, unlike 
you, I spotted them after you replied, so I've muddied the discussion with them.

Here's what I should have said about the original example:

  - It shows how to use .ss to insert extra (discardable) horizontal space 
without overriding its normal use to also separate words and sentences.  That 
is, in the original example, one of the footnotes could have consisted of more 
than one sentence, and groff would use its usual spaces to separate words and 
sentences while still putting the extra-wide space between footnotes.

  - It shows that .ss will take effect multiple times on the same output line.

So I got the details wrong, but with the above finessing I think my main points 
stand.


I'll reply to some of your specific responses out of order:

On 3/25/21, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> The _main_ thing I wanted to illustrate was
> the use of the _second_ argument to .ss. 

A valid point, though I still suspect that's a straightforward enough 
application of the basic .ss description that it might not warrant an example 
illustrating only that.

> the original example _does not illustrate the use of
> the second argument to .ss_, which I think is a flaw given the
> context.  In fact, the _only_ groff feature it uses is the .nop
> request.

Therein lies a worthy philosophical question: should the Texinfo examples 
strive to illustrate groff-specific features, or general language features?  
The manual overall seems to presume no existing roff knowledge, so arguably the 
examples should be illustrating the roff language as a whole.

However, see my final paragraph below.

> I find .nop to be poorly-named

No argument there.

> if I understood all of the use cases that motivated it I'd
> be happy to add them to our manual.

Agreed, the .nop section is a prime candidate for some good examples of where 
that request is useful; like you, I don't have any readily available.  Does 
anyone out there use this regularly and have some simple examples?  If that 
hole were filled in, it would be less important to retain uses of .nop in 
unrelated snippets.

> By changing the .nop request into a pair of spaces you can,
> perhaps, achieve the same result with only CSTR #54 features.  (I say
> "perhaps" because V7 Unix troff didn't honor the .ss request for nroff
> devices at all, and Heirloom doesn't seem to either).  I'll call this
> "Example 3".
>
> .ll 4.5i
> 1.\ This is the first footnote.\c
> .ss 48
>   \" 2 spaces
> .ss 12
> 2.\ This is the second footnote.
>
> The above works on groff equivalently to the old original example.

Good point.  (Incidentally, two spaces aren't necessary; one is sufficient.)  
But I think which is better is a judgment call.

Were I using this technique in production code, I'd probably use the .nop 
formulation because I find it cleaner than a line containing only space (or 
alternatively, as above, space followed by a comment).  The .nop might still 
warrant a comment to explain what it's doing, but the comment at least wouldn't 
need to point out the .nop's very existence.

But in a short example illustrating a novel .ss usage, keeping the focus on 
that and not bringing in more other requests than necessary has its advantages 
too.

Whittling your Example 3 down to only CSTR #54 features further drives home 
that the implementation matters: This snippet does what you want in groff, and 
does not in Heirloom troff, regardless of what extension level you specify.  
Whether this is a functional change that warrants an explicit mention in the 
manual, I'm not sure.  This might be an unintentional limitation (or a bug) in 
the original code; I don't think anything in CSTR #54 indicates that this 
*shouldn't* work.  Thus, while groff seems to depart from historical behavior 
here, it's not clear that it departs from historical *intent*.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]