rust-lang
Option to use blocks in fill match arms
It would be nice if there was a configuration setting to use blocks in the fill match arm assist to avoid having to needlessly delete todo! and the comma and add curly braces in each match arm when I want to use more complex code.
Maybe it would even make sense to implement this as two different code actions so one could easily choose which variant would make sense for this particular bit of code.
I'm not a big fan of making this a setting, because I think this is something you usually decide for each match or even match arm. I think the nicest approach would be if it would be easier to overwrite the todo! with a block; maybe we could do this with on-type-formatting? E.g. something like if you have /*cursor*/todo!(), and type { it deletes the todo!(),.
Well, that would still require the user to go to every todo! and type a {
Personally I am not a big fan of the single-line match-arms for anything but the smallest values as they tend to be a lot less readable than using the blocks (very noisy block of characters if you have a few lines like that with very little whitespace) and also usually tend to be indented pretty far already so I do add blocks in almost every match I use.
Personally I am not a big fan of the single-line match-arms for anything but the smallest values as they tend to be a lot less readable than using the blocks
Sure, but a lot of match arms are very small, e.g. just a break/return.
I think it depends a lot on personal coding style. It seems in the rust-analyzer source code a lot of things are written in the one-line notation, even things I would consider quite long.
I have checked the rust-analyzer codebase (for lack of an easy way to do it on a number of crates) with this command to find the distribution of the number of characters after the =>
grep -h '=> [^{]' **/*.rs | sed -e 's/^.*=> //' | while read e; do echo -n "${e}" | wc -c; done | sort | uniq -c | sort -n -k 2,2
The first column is the count and the second is the number of characters.
30 1
109 2
391 3
70 4
393 5
194 6
119 7
81 8
152 9
108 10
196 11
223 12
117 13
102 14
97 15
95 16
106 17
71 18
91 19
84 20
86 21
73 22
65 23
67 24
72 25
48 26
63 27
50 28
46 29
60 30
57 31
49 32
40 33
54 34
48 35
54 36
35 37
60 38
44 39
32 40
33 41
33 42
37 43
28 44
33 45
13 46
23 47
24 48
18 49
47 50
9 51
11 52
11 53
7 54
4 55
8 56
7 57
4 58
9 59
2 60
5 61
9 62
10 63
4 64
4 65
4 66
2 67
3 68
3 69
1 71
3 72
3 74
1 75
1 78
2 83
1 84
1 91
1 98
1 107
1 108
1 116
2 117
Keep in mind that this does not found characters for indentation, pattern and guard as well as the => itself.
In total there are 4356 lines using no open curly brace after a => and 2127 using one in that position.
Since that is quite similar in number maybe some ability to control it for each invocation would be useful.
Instead of creating a block/another code action, we can place multiple cursors at the beginning of each todo!(). Then you can replace them easily, and we avoid having to duplicate an assist, and also can do that using a more find-grainded approach.
As long as that works with coc.nvim in vim (which is the editor and LSP implementation I am using) that would be fine with me. I tried to find that information but it seems there are some conflicting sources. I haven't worked with multiple cursors before.
Well I'm not working with vim so I have no idea. It seems like vim has plugins to do that, e.g. https://github.com/mg979/vim-visual-multi, but they denied this feature request until this is native support from vim.
That was one source I found too but then there are plugins like https://github.com/mg979/vim-visual-multi which do seem to support multiple cursors. I certainly agree with the poster in that issue you mentioned who said the terminology around multiple cursors is far from ideal.
Multiple cursors seems to be a relatively niche feature as far as editors with support for it go as well as people convinced that it is a good idea in general since it breaks a lot of other features (see e.g. https://medium.com/@schtoeffel/you-don-t-need-more-than-one-cursor-in-vim-2c44117d51db ) . It might be sensible to have an option for all the other editors out there which do not support it and for the people who do not like to use it.
I think blocks would be a better default since if you end up putting something really small in the block then rustfmt will usually remove the {}s which saves a lot of energy over being forced to manually remove all the todo!()s. There is also the annoying side effect of the todo!s producing warnings in the compiler if there is any code below the match due to #[warn(unreachable_code)].
I support this. Was looking if anyone had a solution to this, am constantly going through manually replacing todo!s with {} before I start thinking about the problem! Would be fantastic to set it to use {} as a default instead of todo!()
