Skip to content

[Feature Request] format range support #7580

New issue

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

Closed
0x8f701 opened this issue Feb 6, 2021 · 3 comments · Fixed by #8767
Closed

[Feature Request] format range support #7580

0x8f701 opened this issue Feb 6, 2021 · 3 comments · Fixed by #8767
Labels
S-unactionable Issue requires feedback, design decisions or is blocked on other work

Comments

@0x8f701
Copy link

0x8f701 commented Feb 6, 2021

image

I keep getting this error messages recently. It seems RA will send formatSelected notification when the width of current line becomes greater than rustfmt.toml 's max_width.

And in this case coc.nvim throw out an error that RA doesn't support range formatting.

Peek 2021-02-06 22-58

I'm wondering if it's possible to support range formatting in RA? Or shall I consider this as a coc.nvim's UX issue?

@flodiebold
Copy link
Member

I'd consider it a UX issue or misconfiguration in coc.nvim that it tries to do this when it's not supported.

That said, in principle I think range formatting is something we should support; I'm not sure what the status of that in rustfmt is though. If it's supported by rustfmt by now, it shouldn't be too hard to implement. Otherwise it will have to wait for our own formatting infrastructure (#1665 / #4182).

@flodiebold flodiebold added the S-unactionable Issue requires feedback, design decisions or is blocked on other work label Feb 6, 2021
@bjorn3
Copy link
Member

bjorn3 commented Feb 6, 2021

Rustfmt has experimental support for range formatting on the nightly channel:

$ rustfmt +nightly --help=file-lines
If you want to restrict reformatting to specific sets of lines, you can
use the `--file-lines` option. Its argument is a JSON array of objects
with `file` and `range` properties, where `file` is a file name, and
`range` is an array representing a range of lines like `[7,13]`. Ranges
are 1-based and inclusive of both end points. Specifying an empty array
will result in no files being formatted. For example,

```
rustfmt --file-lines '[
    {"file":"src/lib.rs","range":[7,13]},
    {"file":"src/lib.rs","range":[21,29]},
    {"file":"src/foo.rs","range":[10,11]},
    {"file":"src/foo.rs","range":[15,15]}]'
```

would format lines `7-13` and `21-29` of `src/lib.rs`, and lines `10-11`,
and `15` of `src/foo.rs`. No other files would be formatted, even if they
are included as out of line modules from `src/lib.rs`.

@Jesse-Bakker
Copy link
Contributor

Jesse-Bakker commented Feb 9, 2021

I wonder if it would be possible to do some processing on selected syntax to make it valid rust syntax and then run it through rustfmt as if it was a file and at the end strip off the added syntax. At first glance, the processing needed would be to expand or shrink the selection to a valid AstNode and then wrap it in a function. For example:

let a=2;

With =2 selected. First, expand the selection to a=2, then
->

fn fmt_dummy_name() {
a=2
}

-> rustfmt

fn fmt_dummy_name() {
    a = 2
}

->

a = 2

This may be a bit hacky, but it works on stable 😁. Of course ra-format or rustfmt support would be better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-unactionable Issue requires feedback, design decisions or is blocked on other work
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants