git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Eric Sunshine <ericsunshine@gmail.com>
Cc: Patrick Steinhardt <ps@pks.im>,
	git@vger.kernel.org, Ezekiel Newren <ezekielnewren@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 2/6] ci: check formatting of our Rust code
Date: Tue, 7 Oct 2025 22:42:16 +0000	[thread overview]
Message-ID: <aOWXSO5GInJI8-NZ@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <CAPig+cQ7xJky+F=g=NMrN6BQfP+ZV2KF4RF2eLqtULKgMTR5_g@mail.gmail.com>

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

On 2025-10-07 at 17:13:18, Eric Sunshine wrote:
> Later in the same thread, I wrote[2]:
> 
>     Project guidelines have long suggested 80 columns as a desirable
>     maximum not only for C code, but for pretty much all other
>     resources, including shell code, Perl code, and documentation
>     files. This suggested maximum works well for adherents of
>     80-columns and (presumably) hasn't been too onerous for developers
>     who use wider windows; at least we haven't heard people clamoring
>     to increase the suggested maximum column limit. As such, it does
>     not seem far-fetched to expect that the project guidelines
>     should/could/would also apply to Rust code.

My preference is actually that we stick with the default.  I use (and
for a long time have used) a 132-character editor window and I find it
quite useful to have the extra space.  The DEC VT100 did 132 columns
(available on your local Linux system as `vt100-w`), so I think there's
plenty of precedent for that being an acceptable width[0].

I did previously use 80-column terminals when I had a tiny laptop
screen, but modern display resolutions over the past decade, even on
smaller laptops, have made it entirely possible to get several wider
terminal windows (or in my case, tmux panes) on one screen.  One of my
current tmux panes is now 213×54 and I really enjoy the extra space.

The default Rust behaviour is 100 characters[1], which I think is a fine
default.  I won't be enormously angsty if we say we still absolutely
must stick to 80-character lines, but I also think we should take this
opportunity to choose the Rust defaults for Rust.  C, Perl, and text
formats like AsciiDoc do not have rigid defaults about indentation
style, tabs vs. spaces, and line length; Rust does.  We wouldn't use
tabs in Rust (the default is four spaces) because we use it everywhere
else, so I think we should take the opportunity to use the Rust defaults
here as well.

Whatever we ultimately decide, I plan to send an update to our
`.editorconfig` file.  I think that's less useful in general for Rust,
where we have an automatic tidy tool and CI to check for it, but there
are some people for whom it will be useful and we might as well keep it
correct.

[0] For what it's worth, Linus also thinks longer lines and 132-column
terminals are useful.  I don't agree with him about everything,
certainly, but I think we see eye to eye here:
https://lkml.org/lkml/2020/5/29/1038.
[1] % rustfmt --print-config=default /dev/stdout | grep '^max_width'
max_width = 100
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

  parent reply	other threads:[~2025-10-07 22:42 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-07 12:36 [PATCH 0/6] ci: improvements to our Rust infrastructure Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 1/6] ci: deduplicate calls to `apt-get update` Patrick Steinhardt
2025-10-07 12:54   ` Karthik Nayak
2025-10-14 20:56   ` Justin Tobler
2025-10-07 12:36 ` [PATCH 2/6] ci: check formatting of our Rust code Patrick Steinhardt
2025-10-07 13:04   ` Karthik Nayak
2025-10-07 13:50     ` Patrick Steinhardt
2025-10-07 17:13   ` Eric Sunshine
2025-10-07 17:38     ` Junio C Hamano
2025-10-07 18:03       ` Eric Sunshine
2025-10-07 22:42     ` brian m. carlson [this message]
2025-10-07 22:58       ` Chris Torek
2025-10-08  4:46       ` Patrick Steinhardt
2025-10-08 15:34         ` Junio C Hamano
2025-10-09  5:29           ` Patrick Steinhardt
2025-10-29 22:54           ` SZEDER Gábor
2025-10-07 22:07   ` brian m. carlson
2025-10-08 20:55   ` SZEDER Gábor
2025-10-09  5:29     ` Patrick Steinhardt
2025-10-29 21:19       ` SZEDER Gábor
2025-10-07 12:36 ` [PATCH 3/6] rust/varint: add safety comments Patrick Steinhardt
2025-10-08  0:29   ` brian m. carlson
2025-10-08  4:46     ` Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 4/6] ci: check for common Rust mistakes via Clippy Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 5/6] ci: verify minimum supported Rust version Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 6/6] rust: support for Windows Patrick Steinhardt
2025-10-15  6:04 ` [PATCH v3 0/6] ci: improvements to our Rust infrastructure Patrick Steinhardt
2025-10-15  6:04   ` [PATCH v3 1/6] ci: deduplicate calls to `apt-get update` Patrick Steinhardt
2025-10-15  6:04   ` [PATCH v3 2/6] ci: check formatting of our Rust code Patrick Steinhardt
2025-10-15  6:04   ` [PATCH v3 3/6] rust/varint: add safety comments Patrick Steinhardt
2025-10-15  6:04   ` [PATCH v3 4/6] ci: check for common Rust mistakes via Clippy Patrick Steinhardt
2025-10-15  6:04   ` [PATCH v3 5/6] ci: verify minimum supported Rust version Patrick Steinhardt
2025-10-15  6:04   ` [PATCH v3 6/6] rust: support for Windows Patrick Steinhardt
2025-11-20 19:45     ` Ezekiel Newren
2025-11-21  8:18       ` Johannes Schindelin
2025-11-21 21:39         ` Junio C Hamano
2025-10-15 15:21   ` [PATCH v3 0/6] ci: improvements to our Rust infrastructure Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aOWXSO5GInJI8-NZ@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=ericsunshine@gmail.com \
    --cc=ezekielnewren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).