Re: style question as by commit dbcfe3eb6 / Aid Vim editor

"G. Branden Robinson" <[email protected]> Tue, 17 Mar 2026 07:01:14 -0500
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260317120114.hwna3toqy3kuv6s4@illithid>
Hi Norwid,

At 2026-03-17T07:56:17+0000, Norwid Behrnd wrote:
> I read your commit dbcfe3eb6 / Aid Vim editor which provides
> `src/devices/xditview/xditview[.c]` the instruction
> 
> ```
> vim:set cindent noexpandtab shiftwidth=4 softtabstop=4 textwidth=72:
> ```
> 
> This is in contrast to `/contrib/chem/chem.pl` with the line
> 
> ```
> # vim: set cindent noexpandtab shiftwidth=2 softtabstop=2 textwidth=72:
> ```
> 
> Do you think the former pattern (including `4` on `shiftwidth` and
> `softtabstop`) were equally useful here, for consistency of style?

Each of those files is noteworthy in that they are "foreign" to groff,
and each in a distinct way.

Much of the code in src/devices/xditview comes from X11R4 (1989).

"chem" is in our "contrib" area.  That specific project is Bernd
Warken's and reflects his code style preferences.

Consequently their indentation practices may differ from each other and
from code originating in groff as well.  I'm not enthusiastic about
churning a source file just to align its indentation amount with groff's
"norm", which is not written down anywhere anyway.

> In addition, `chem`'s example files recently edited
> (`contrib/chem/examples` excluding the ones of sub folder `cstr-122`)
> sometimes have the note of `textwidth=72` as one (and only) guideline
> for vim, sometimes they do not.  Would you prefer that these equally
> include the complete line (with both `shiftwidth` and `softtabstop`
> set to `4`) -- again for consistency, or with `textwidth=72` only, or
> be without such an indication at all?  The later pattern is seen for
> instance on each example file in `contrib/chem/examples/cstr-122`
> except for `ch2a_ethyl.chem`, ch4a_stick.chem`, and
> `ch4j_ring4.chem`).

My rule of thumb is that I add (or update) a Vim modeline only when the
absence of one "gets in my way" (compels me to type additional
keystrokes while editing, to maintain the file's style).

I feel more strongly about the 72-column limit than any other element of
a modeline because it makes code more quotable in email and makes
side-by-side diffing tractable in more environments.  The value 72
also has a storied history bound up with the 80-column "standard", one
that becomes more perceptible when one does things like piping a file
through nl(1) or using vi(1)'s ":set number".

So for instance with the chem examples, if all the input lines are
really short, I don't experience the foregoing compulsion to add a Vim
modeline.  However, if one is already present, I won't take it out.

These practices are consistent with what I perceive to be the purpose of
vi(m) modelines and Emacs local variables; they're supposed to _aid_ you
while performing editing tasks.  Where they deliver no benefit, they are
unnecessary and need not be included.  Superficial lexical consistency
with other files in the groff source tree is not an objective I have.

On that note I question the utility of the chem examples' practice of
declaring (to Emacs) that the Nroff major mode should be used in their
editing.  The syntax of the _chem_ language is pretty different from
*roff's.  chem(1) input, apart from the tokens used to delimit within a
*roff context, more closely resembles those of eqn(1) and pic(1).  That
Kernighan had a hand in all of these is no coincidence, I think.  (To
me, it's clear that he was a much bigger fan of readable source code
than several of his Bell Labs CSRC colleagues.)

So, to answer your questions, no, I don't reckon that I have a strong
preference here.  Ergonomics is (are?) king.

Regards,
Branden
signature.asc (application/pgp-signature, 833 B)