Skip to content

Remove colorcolumn setting from Vim runtime files#6783

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

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

Conversation

@hoelzro
Copy link
Copy Markdown
Contributor

@hoelzro hoelzro commented May 28, 2013

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

@bstrie
Copy link
Copy Markdown
Contributor

bstrie commented May 28, 2013

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.
@bors bors 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-bors bot 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.
Sign up for free to 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