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
Description: PGP signature
