Yeah I have a lot of these cases too. Really wish there was a way to turn off auto-formatting for blocks then turn back on after…
OvermindDL1
josevalim
Creator of Elixir
Oh yeah, I totally agree it is worse in this case. Tuples feel awkward when expanding one per line, maybe we could do something about it. Can you please open up issue?
If you could provide examples it would be helpful. For instance, seeing the example above makes it clear the code is worst regardless of taste.
1
OvermindDL1
Here was one from one of my work projects (a port from one of my old erlang libraries with some more features):
Before the formatter:
def permutations do
{
151, 160, 137, 91, 90, 15, 131, 13, 201, 95, 96, 53, 194, 233, 7, 225, 140, # Each row defines a dimension
36, 103, 30, 69, 142, 8, 99, 37, 240, 21, 10, 23, 190, 6, 148, 247, 120,
234, 75, 0, 26, 197, 62, 94, 252, 219, 203, 117, 35, 11, 32, 57, 177, 33,
88, 237, 149, 56, 87, 174, 20, 125, 136, 171, 168, 68, 175, 74, 165, 71,
134, 139, 48, 27, 166, 77, 146, 158, 231, 83, 111, 229, 122, 60, 211, 133,
230, 220, 105, 92, 41, 55, 46, 245, 40, 244, 102, 143, 54, 65, 25, 63, 161,
1, 216, 80, 73, 209, 76, 132, 187, 208, 89, 18, 169, 200, 196, 135, 130,
116, 188, 159, 86, 164, 100, 109, 198, 173, 186, 3, 64, 52, 217, 226, 250,
124, 123, 5, 202, 38, 147, 118, 126, 255, 82, 85, 212, 207, 206, 59, 227,
47, 16, 58, 17, 182, 189, 28, 42, 223, 183, 170, 213, 119, 248, 152, 2, 44,
154, 163, 70, 221, 153, 101, 155, 167, 43, 172, 9, 129, 22, 39, 253, 19, 98,
108, 110, 79, 113, 224, 232, 178, 185, 112, 104, 218, 246, 97, 228, 251, 34,
242, 193, 238, 210, 144, 12, 191, 179, 162, 241, 81, 51, 145, 235, 249, 14,
239, 107, 49, 192, 214, 31, 181, 199, 106, 157, 184, 84, 204, 176, 115, 121,
50, 45, 127, 4, 150, 254, 138, 236, 205, 93, 222, 114, 67, 29, 24, 72, 243,
141, 128, 195, 78, 66, 215, 61, 156, 180, 151, 160, 137, 91, 90, 15, 131,
13, 201, 95, 96, 53, 194, 233, 7, 225, 140, 36, 103, 30, 69, 142, 8, 99, 37,
240, 21, 10, 23, 190, 6, 148, 247, 120, 234, 75, 0, 26, 197, 62, 94, 252,
219, 203, 117, 35, 11, 32, 57, 177, 33, 88, 237, 149, 56, 87, 174, 20, 125,
136, 171, 168, 68, 175, 74, 165, 71, 134, 139, 48, 27, 166, 77, 146, 158,
231, 83, 111, 229, 122, 60, 211, 133, 230, 220, 105, 92, 41, 55, 46, 245,
40, 244, 102, 143, 54, 65, 25, 63, 161, 1, 216, 80, 73, 209, 76, 132, 187,
208, 89, 18, 169, 200, 196, 135, 130, 116, 188, 159, 86, 164, 100, 109, 198,
173, 186, 3, 64, 52, 217, 226, 250, 124, 123, 5, 202, 38, 147, 118, 126,
255, 82, 85, 212, 207, 206, 59, 227, 47, 16, 58, 17, 182, 189, 28, 42, 223,
183, 170, 213, 119, 248, 152, 2, 44, 154, 163, 70, 221, 153, 101, 155, 167,
43, 172, 9, 129, 22, 39, 253, 19, 98, 108, 110, 79, 113, 224, 232, 178, 185,
112, 104, 218, 246, 97, 228, 251, 34, 242, 193, 238, 210, 144, 12, 191, 179,
162, 241, 81, 51, 145, 235, 249, 14, 239, 107, 49, 192, 214, 31, 181, 199,
106, 157, 184, 84, 204, 176, 115, 121, 50, 45, 127, 4, 150, 254, 138, 236,
5, 93, 222, 114, 67, 29, 24, 72, 243, 141, 128, 195, 78, 66, 215, 61, 156,
180, # Trailing value as a catch-all
}
end
And post-formatter:
def permutations do
{
# Each row defines a dimension
151,
160,
137,
91,
90,
15,
131,
13,
201,
95,
96,
53,
194,
233,
7,
225,
140,
36,
103,
30,
69,
142,
8,
99,
37,
240,
21,
10,
23,
190,
6,
148,
247,
120,
234,
75,
0,
26,
197,
62,
94,
252,
219,
203,
117,
35,
11,
32,
57,
177,
33,
88,
237,
149,
56,
87,
174,
20,
125,
136,
171,
168,
68,
175,
74,
165,
71,
134,
139,
48,
27,
166,
77,
146,
158,
231,
83,
111,
229,
122,
60,
211,
133,
230,
220,
105,
92,
41,
55,
46,
245,
40,
244,
102,
143,
54,
65,
25,
63,
161,
1,
216,
80,
73,
209,
76,
132,
187,
208,
89,
18,
169,
200,
196,
135,
130,
116,
188,
159,
86,
164,
100,
109,
198,
173,
186,
3,
64,
52,
217,
226,
250,
124,
123,
5,
202,
38,
147,
118,
126,
255,
82,
85,
212,
207,
206,
59,
227,
47,
16,
58,
17,
182,
189,
28,
42,
223,
183,
170,
213,
119,
248,
152,
2,
44,
154,
163,
70,
221,
153,
101,
155,
167,
43,
172,
9,
129,
22,
39,
253,
19,
98,
108,
110,
79,
113,
224,
232,
178,
185,
112,
104,
218,
246,
97,
228,
251,
34,
242,
193,
238,
210,
144,
12,
191,
179,
162,
241,
81,
51,
145,
235,
249,
14,
239,
107,
49,
192,
214,
31,
181,
199,
106,
157,
184,
84,
204,
176,
115,
121,
50,
45,
127,
4,
150,
254,
138,
236,
205,
93,
222,
114,
67,
29,
24,
72,
243,
141,
128,
195,
78,
66,
215,
61,
156,
180,
151,
160,
137,
91,
90,
15,
131,
13,
201,
95,
96,
53,
194,
233,
7,
225,
140,
36,
103,
30,
69,
142,
8,
99,
37,
240,
21,
10,
23,
190,
6,
148,
247,
120,
234,
75,
0,
26,
197,
62,
94,
252,
219,
203,
117,
35,
11,
32,
57,
177,
33,
88,
237,
149,
56,
87,
174,
20,
125,
136,
171,
168,
68,
175,
74,
165,
71,
134,
139,
48,
27,
166,
77,
146,
158,
231,
83,
111,
229,
122,
60,
211,
133,
230,
220,
105,
92,
41,
55,
46,
245,
40,
244,
102,
143,
54,
65,
25,
63,
161,
1,
216,
80,
73,
209,
76,
132,
187,
208,
89,
18,
169,
200,
196,
135,
130,
116,
188,
159,
86,
164,
100,
109,
198,
173,
186,
3,
64,
52,
217,
226,
250,
124,
123,
5,
202,
38,
147,
118,
126,
255,
82,
85,
212,
207,
206,
59,
227,
47,
16,
58,
17,
182,
189,
28,
42,
223,
183,
170,
213,
119,
248,
152,
2,
44,
154,
163,
70,
221,
153,
101,
155,
167,
43,
172,
9,
129,
22,
39,
253,
19,
98,
108,
110,
79,
113,
224,
232,
178,
185,
112,
104,
218,
246,
97,
228,
251,
34,
242,
193,
238,
210,
144,
12,
191,
179,
162,
241,
81,
51,
145,
235,
249,
14,
239,
107,
49,
192,
214,
31,
181,
199,
106,
157,
184,
84,
204,
176,
115,
121,
50,
45,
127,
4,
150,
254,
138,
236,
5,
93,
222,
114,
67,
29,
24,
72,
243,
141,
128,
195,
78,
66,
215,
61,
156,
# Trailing value as a catch-all
180
}
end
And that is just one of many things in a variety of formats that just utterly visually break when the formatter is ran over them (mostly in this project, math stuff).
So yes, until the formatter supports a way to ignore entire blocks of code I will not be able to use it in quite a few areas… ^.^;
1
NobbZ
Nearly all kind of tabular data:
@option_spec [
{"foo", ?f, "Does a foo", :boolean, false},
{"borbarad", ?b, "Master of dreams and death", :boolean, false},
{"verbose", ?v, "Set verbosity level", :integer, 0}
]
1
mischov
I opened an issue on the formatter hurting readability, if people want to add examples there.
EDIT: Actually, as per José’s request, please don’t add examples of different readability issues there. If you have a similar problem that’s not related to the formatting of tuples, open a different issue
3
josevalim
Creator of Elixir
For this particular case, I would build a list using ++ and then convert it to a tuple.
Yes, tabular data will be lost by design because it almost always forces unrelated changes when adding larger entries.
1
tmbb
I’m going to ask for something really stupid, but which makes sense and I’ll regret it for the rest of my life if I don’t ask it now: if there are going to be “special” comments in Elixir (to direct the formatter, for example), make them so that a non-whitespace character follows the # character. That is, do this:
#! special
Instead of this
# !special
If such comments could be standardized on a single symbol, like !, it would be even better.
I’m asking this because of my “inverse literate programming tool”, which treats comments as text and could render comments like #! special stuff as literal comments instead. I know my library is used by exactly on person (me), but it was released 5 hours ago and I think that people who work with Elixir source might be happy about a standardized format for such comments.
0
NobbZ
So why did you remove trailing comma then?
I do accept your decission this way or the other, but I’d be happy about a magic comment that lets me turn of the formatter for a couple of lines, because for matter hurts more here than it helps.
0
OvermindDL1
Except I’m baking it into the module at compile-time for speed reasons (it really helps in these cases).
I guess I could unquote it inline, but doing multiple lists, concat’ing them, then turning (piping) into a tuple, all within an unquote seems exceedingly and almost stupidly verbose and will make me look over the code as Wth is going on here?!? every time I look at it when I’ve forgotten about it, that should just not be done… o.O!
A lot of my things in the same project are tabular as well, some math matrices, and the formatter fubars them to heck as well.
I have no clue what should be done… ^.^;
Comments is pretty common in the C++ world to control the formatter, I bet it is elsewhere too. But I could see module definitions be used as well though that would constrain you to the module level which is not so good…
I don’t really care how it gets defined to skip, as long as it is not something irritating like a configuration file that let’s you skip a set of lines that would inevitably get out of sync over time… ^.^;
Yeah I agree as well. Multi-line lists/tuples/maps/etc… should *always*always*always* keep the trailing comma to allow for easy sorting and moving of lines at the very least (plus consistency!).
2
josevalim
Creator of Elixir
The fact we are rewriting this is really bad, haha. Please open up another issue. 
Let’s please not make that a generic issue for formatter problems because then it will be impossible to tackle it. We already have a great example, so let’s improve that, we can always open up more issues as necessary.
1