[Top][All Lists]

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

Re: Warn about long lines

From: Alejandro Colomar
Subject: Re: Warn about long lines
Date: Sun, 28 Aug 2022 15:03:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2

Hi Branden,

On 8/27/22 20:02, G. Branden Robinson wrote:
Hi Alex,

At 2022-08-27T19:42:43+0200, Alejandro Colomar wrote:
Lines with highlighting have more characters than visible.  Of course,
in my 80 limit, I only want to count visible ones, so I need to get
rid of the highlighting.  I started with using [[:print:]] in grep(1),
but it also counted part of the multibyte sequences of the
highlighting (i.e., it didn't count the character that introduced the
escape sequence, but counted the rest; more or less, what you'd see if
you run less without -R; e.g., '[1m').  So I used this, as a big
cannon; probably shooting more than necessary; I wanted to make sure
no traces remained.

At some point you're going to hit the problem of printable UTF-8
sequences that occupy more than one byte but only one character cell.

Hitted.  Heh!  Boxed tables.  Fixed with -Tascii.

Although in this case it's for running groff(1)'s warnings, for which
I'll need to run groff(1).

No, you're not running it for groff(1)'s warnings, you're running it for
the formatter's warnings.  The formatter is troff(1) and groff(1) always
runs it.

Makes sense. Good to know. So, I prefer the explicit pipeline, so I know what really is going on. I hope this will improve the quality of my bug reports, and my debugging abilities.

Do I get the same warnings by passing -ww and -rCHECKSTYLE=3 to
troff(1) and to groff(1)?  or does groff(1) have extra warnings (maybe
since it also has access to the tbl(1) input)?

Slow down there.  groff itself has only one warning.

   warning("-TXps option is obsolete: use -X -Tps instead");

It also has a few error diagnostics because it attempts to locate the
'DESC' file for the output device and from there determine what
preprocessor (if any) and posprocessor it needs to run.

None of this has to do with the content of your document.

Good to know.

The data between troff(1) and grotty(1), or any other post-processor,
is in groff_out(5) format and what marks to put where has already been
decided, fixing the line length.

The man macros realise the man command might be on a terminal of varying
width or producing ‘cat’ man pages for storage.  To allow the man
command to specify the line-length required, the man macro allows the LL
number register to override what length it would normally use for the
‘.ll’ command.  When the man command runs troff, it uses the -r option
to set the number register.

It doesn't seem like a man(7)-specific thing

It is.

Only sort of.  Registers for setting line length, page offset, page
length, and vertical spacing trickled into the various macro packages in
an inconsistent way over the years.

One of the post-1.23 projects I have in mind is to complete the set for
all macro packages and teach nroff about them so I can do something
highly satisfying: give nroff an option to auto-size output to the
terminal dimensions.

I mean, when searching for an option that controls the line
length, I expect it to be a generic option that will be applicable
to groff as a whole

This was not thought to be necessary in the 1970s, because the media
dimensions were rigidly fixed for Teletype devices and even on the
C/A/T, you had to physically cut the giant roll of "paper" into leaves



Ahh, it makes sense: normally documents are designed to be rendered in
a specific device and characteristics.  It's only manual pages that
are more generic in that regard, in that they are mostly read in
terminals (not their original conception, but that's what it is right

We could have more flexibility than we do.  I began realizing this when
I started working on the document.

groff(1) is a confusing front-end program for the normal troff-based
pipeline so some more interesting options would be in troff(1), for
example.  But in this case, it's not a command-line option.  :-)

-rLL=XXn is very much a groff(1) command line option (that gets passed
to troff(1)) and I have used it for years in my own little shell

$ type gman
gman is a function
gman ()
     local width=$(stty size | cut -d' ' -f2);
     width=$(( width - 1 ));
     local cmd=$(./build/grog -Tutf8 -b -ww -P-i -rU1 -rLL=${LL:-$width}n "$1");
     ./build/test-$cmd | less -R

This width - 1 is a workaround for the issue I saw, but different from what man(1) does. I wonder why all these workarounds exist.




Alejandro Colomar

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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