Skip to content

Remove colorcolumn setting from Vim runtime files - #6783

Closed
hoelzro wants to merge 1 commit into
rust-lang:masterfrom
hoelzro:master
Closed

Remove colorcolumn setting from Vim runtime files#6783
hoelzro wants to merge 1 commit into
rust-lang:masterfrom
hoelzro:master

Conversation

@hoelzro

Copy link
Copy Markdown
Contributor

I think settings like this should be left up to the user.

@bstrie

Copy link
Copy Markdown
Contributor

We talked about this a bit and I think this is the correct course of action. I originally put in the colorcolumn rule because our original convention of 78 columns was shorter than the typical users' worst-case column length (80), and also because it was short enough that people were hitting it constantly. Now that we've increased the convention to 100 columns, the complaints of hitting the line-length limit during make check have all but vanished, which leads me to believe that a default setting to warn of the limit is no longer necessary. Also, some people would rather use textwidth to enforce their line lengths, rather than colorcolumn.

Furthermore, ideally the hypothetical rustfmt would save us from ever worrying about column lengths at all. Let us boldly stride towards that utopian future.

bors added a commit that referenced this pull request May 28, 2013
I think settings like this should be left up to the user.
@borsbors closed this May 28, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Feb 25, 2021
Add OpenDNS to `doc-valid-idents`
changelog: This commit adds `"OpenDNS"` to doc-valid-idents to avoid `doc_markdown` false positives.
rust-borsBot pushed a commit that referenced this pull request Feb 27, 2026
* chore: add `crossbeam-channel` as a dependency for the mpmc channel
* refactor: package up all the git repository details in `Repository`
* refactor: encapsulate logic for cloning repositories
* refactor: add `check_diff_for_file` to support parallel file checks
Processing all files in parallel is more efficient than checking each
repo in parallel.
One issue with the current design of processing each repo in parallel is
that threads that process smaller repos end early and don't help process
files from larger repos. For example, r-l/rust is a large repo that
takes a long time to check because there's only one thread working on
it.
Besides enabling us to process all files in parallel,
`check_diff_for_file` return a `Result<(), (Diff, ..)>` instead of a
`u8`, which is a more idiomatic way to represent any errors we find when
checking for diffs.
* refactor: process files in parallel and report errors at the end
Now we'll process each file in parallel instead of processing each repo
in parallel, and after checking all repositories we'll report on any
errors that we've found.
* feat: Add `worker_threads` option
This option control how many threads process files in parallel.
Setting the default to 16 as that's a common multiple of CPU cores.
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
6783: Avoid nesting Subtrees when parsing TokenStream r=jonas-schievink a=jonas-schievink
Fixesrust-lang/rust-analyzer#6744
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@hoelzro@bstrie@bors