We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
:reflow
I would expect that running :reflow on a selection and then running it again would have no effect the second time, but this is not always the case. For example with the file https://github.com/red-hat-storage/ocs-osd-deployer/blob/main/controllers/managedocs_controller.go, running reflow repeatedly will continue to change it.
I believe this is an upstream bug with the textwrap crate. Running this code will print constantly change text length
fn main() { let mut text = std::fs::read_to_string("managedocs_controller.go").unwrap(); loop { text = textwrap::refill(&text, 79); dbg!(text.len()); } }
[src/main.rs:5] text.len() = 66194 [src/main.rs:5] text.len() = 65970 [src/main.rs:5] text.len() = 65924 [src/main.rs:5] text.len() = 65931 [src/main.rs:5] text.len() = 65938 [src/main.rs:5] text.len() = 65945 [src/main.rs:5] text.len() = 65952 [src/main.rs:5] text.len() = 65959 [src/main.rs:5] text.len() = 65966 [src/main.rs:5] text.len() = 65973 [src/main.rs:5] text.len() = 65980 [src/main.rs:5] text.len() = 65987 [src/main.rs:5] text.len() = 65994 [src/main.rs:5] text.len() = 66001 [src/main.rs:5] text.len() = 66008 [src/main.rs:5] text.len() = 66015 [src/main.rs:5] text.len() = 66022 [src/main.rs:5] text.len() = 66029 [src/main.rs:5] text.len() = 66036 [src/main.rs:5] text.len() = 66043 [src/main.rs:5] text.len() = 66050 [src/main.rs:5] text.len() = 66057 [src/main.rs:5] text.len() = 66064 [src/main.rs:5] text.len() = 66071 [src/main.rs:5] text.len() = 66078 [src/main.rs:5] text.len() = 66085 [src/main.rs:5] text.len() = 66092 [src/main.rs:5] text.len() = 66099 [src/main.rs:5] text.len() = 66106 [src/main.rs:5] text.len() = 66113 [src/main.rs:5] text.len() = 66120 [src/main.rs:5] text.len() = 66127 [src/main.rs:5] text.len() = 66126 [src/main.rs:5] text.len() = 66119 [src/main.rs:5] text.len() = 66126 and so on...
asciinema
In order to reproduce have to check out PR #3733 which fixes an unrelated bug with :reflow panicking
I tried this:
hx managedocs_controller.go
%
I expected this to happen: No changes on the second reflow
Instead, this happened: Things change on the second reflow (line count goes from 960 to 952)
Empty
Linux
Kitty
PR #3733
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Summary
I would expect that running
:reflow
on a selection and then running it again would have no effect the second time, but this is not always the case. For example with the file https://github.com/red-hat-storage/ocs-osd-deployer/blob/main/controllers/managedocs_controller.go, running reflow repeatedly will continue to change it.I believe this is an upstream bug with the textwrap crate.
Running this code will print constantly change text length
Output
Reproduction Steps
asciinema
In order to reproduce have to check out PR #3733 which fixes an unrelated bug with
:reflow
panickingI tried this:
hx managedocs_controller.go
(file from the link above)%
:reflow
:reflow
again, notice that this changes things againI expected this to happen:
No changes on the second reflow
Instead, this happened:
Things change on the second reflow (line count goes from 960 to 952)
Helix log
Empty
Platform
Linux
Terminal Emulator
Kitty
Helix Version
PR #3733
The text was updated successfully, but these errors were encountered: