Vim indentation broken with long match #14446
Comments
|
Also slow and broken with a (pathologically) long function signature spread across many lines: |
bors
added a commit
that referenced
this issue
Sep 22, 2014
There are currently two huge problems with the indent file: 1. Long list-like things cannot be indented. See #14446 for one example. Another one is long enums with over 100 lines, including comments. The indentation process stops after 100 lines and the rest is in column 0. 2. In certain files, opening a new line at mod level is extremely slow. See [this](https://github.com/mahkoh/posix.rs/blob/master/src/unistd/mod.rs) for an example. Opening a line at the very end and holing \<cr> down will freeze vim temporarily. The reason for 1. is that cindent doesn't properly indent things that end with a `,` and the indent file tries to work around this by using the indentation of the previous line. It does this by recursively calling a function on the previous lines until it reaches the start of the block. Naturally O(n^2) function calls don't scale very well. Instead of recalculating the indentation of the previous line, we will now simply use the given indentation of the previous line and let the user deal with the rest. This is sufficient unless the user manually mis-indents a line. The reason for 2. seems to be function calls of the form ``` searchpair('{\|(', '', '}\|)', 'nbW', 's:is_string_comment(line("."), col("."))') ``` I've no idea what this even does or why it is there since I cannot reproduce the mistake cindent is supposed to make without this fix. Therefore I've simply removed that part.
|
Fixed #17212 |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 5, 2023
internal: Only run typescript CI when VSCode files change
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 22, 2025
) Blocks created by desugaring will not contain an explicit `return`. Do not suggest to add it when the user has no control over the desugared code. Also, ensure that in a `xxx.await` expression, the suggested `return` is emitted before the whole expression, not before the `await` keyword. Fix rust-lang#14411 changelog: [`implicit_return`]: fix proposed `return` position in the presence of asynchronous code
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Try gg=G-ing the following file:
https://gist.github.com/anonymous/87716d9ca0990d52cdff
It's very slow and breaks halfway down.
cc: @chris-morgan
The text was updated successfully, but these errors were encountered: