git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
	Eric Sunshine <ericsunshine@gmail.com>,
	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: Wed, 8 Oct 2025 06:46:06 +0200	[thread overview]
Message-ID: <aOXsjnWBOt0qFGwc@pks.im> (raw)
In-Reply-To: <aOWXSO5GInJI8-NZ@fruit.crustytoothpaste.net>

On Tue, Oct 07, 2025 at 10:42:16PM +0000, brian m. carlson wrote:
> 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.

I am also slightly leaning into the direction of sticking with Rust's
default of 100 characters. It's not substantially more than 80, should
be reasonable to accommodate for in most modern setups, and sticks with
what the remainder of the ecosystem is doing.

So for now I'll leave it at 80 characters. But I don't feel strongly
about this, so if there is a majority in favor of 80 characters I'm
happy to adjust.

Thanks!

Patrick

  parent reply	other threads:[~2025-10-08  4:46 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
2025-10-07 22:58       ` Chris Torek
2025-10-08  4:46       ` Patrick Steinhardt [this message]
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=aOXsjnWBOt0qFGwc@pks.im \
    --to=ps@pks.im \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=ericsunshine@gmail.com \
    --cc=ezekielnewren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    /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).