5 ms·

I read your comment too fast and I almost dismissed it, thinking you were talking, like everyone else, about formatters (gofmt, rustfmt). But what you are sayin

by slx26 7y ago

I read your comment too fast and I almost dismissed it, thinking you were talking, like everyone else, about formatters (gofmt, rustfmt). But what you are saying is much more interesting, as we are all allowed to keep our preferences. Is there any major editor/IDE working on this? You are making me miserable, now that I read this I can't live with just formatters anymore :D

lonelappde 7y ago
Every editor can do this. Apply your formatter when you load a file, and apply the standard formatter whenever you submit a file to another machine.
davnicwil 7y ago
So, this is indeed a very cool idea, the fundamental issue you'd have though is that you can't abstract away from the 'ground truth' formatting at the source control level. You could even sort of brute force this without IDE support by reformatting everything to your preference on git pull and back to ground truth on git stage/push, but when it comes to diffs, merges, etc, you must work in terms of the ground truth formatting. That's not even to mention doing stuff like PR reviews in online tools, not in your local editor/IDE. Going back and forth between the two like this would probably just be counter productive, you're better off just thinking in terms of the ground truth formatting from the start, I'd say. I think while it might be possible under a very narrow set of limitations and usecases, it's probably just a very leaky abstraction to try to 'hide' the actual formatting of code in a text file.
- slx26 7y ago
  I can definitely see it might have quite a few problems. Forest [0] and others even attempt to abstract on syntax, which I generally disagree with as it becomes a problem to learn the language or get help / discuss some things with other people, especially online. I'm not dismissing the default formatter, it's obvious you still need one canonical representation of the code, but I don't think you should view it as "hiding" the formatting. In my view, it's more like opening a web page with one browser or another, or with one device or another. It always looks a bit different. Or maybe I have a theme configured on my main browser or whatever. I like to have my preferences, but if I have to look at the page from another browser, it's not a big deal either. The extra configuration might not be worth it or slightly inconvenient in some cases, but I doubt it's counter productive. The same way as I might prefer to read/write with a certain font or use this or that color palette. Maybe the takeaway is that code is more personal for some people than we like to generally admit. You are talking in a language and you want to be able to express yourself as comfortably as possible. I mean, we have had turing-complete and even "productive/decently ergonomic" languages for a while, and yet a lot of people keeps coming up with new languages, because they are much more than just a tool to get things working. We want to express ourselves as we "think", and formatting may be a small part of that, but it's still a part of it. [0] https://github.com/forest-lang/forest-compiler https://github.com/forest-lang/forest-compiler
  - davnicwil 7y ago
    I definitely agree with most of this but I have to challenge the web browser analogy because that's a scenario where the concept of the view (visual, screen reader, etc) being interpreted from the textual representation is built in - as in, there is no end user who consumes the raw markup as-is. So different end users working with different views is a completey natural and expected thing. I guess that's what's missing to make this work for code. The raw code is intended as the final representation to the end user. Maybe what you'd need to make this work is to build in the concept of formatting to the source control itself, so all the way through the tooling you could 'render' the code as you'd like to see it, and do all operations on it using that view (including diffs, etc). Maybe sort of like you can with syntax highlighting, except with positional formatting instead.
mruts 7y ago
I mean, that’s the most common argument on why tabs are better the spaces. It’s also an argument I tend to be sympathetic too.

by slx26 7y ago

lonelappde 7y ago

Every editor can do this. Apply your formatter when you load a file, and apply the standard formatter whenever you submit a file to another machine.

davnicwil 7y ago

So, this is indeed a very cool idea, the fundamental issue you'd have though is that you can't abstract away from the 'ground truth' formatting at the source control level. You could even sort of brute force this without IDE support by reformatting everything to your preference on git pull and back to ground truth on git stage/push, but when it comes to diffs, merges, etc, you must work in terms of the ground truth formatting. That's not even to mention doing stuff like PR reviews in online tools, not in your local editor/IDE. Going back and forth between the two like this would probably just be counter productive, you're better off just thinking in terms of the ground truth formatting from the start, I'd say. I think while it might be possible under a very narrow set of limitations and usecases, it's probably just a very leaky abstraction to try to 'hide' the actual formatting of code in a text file.

slx26 7y ago
I can definitely see it might have quite a few problems. Forest [0] and others even attempt to abstract on syntax, which I generally disagree with as it becomes a problem to learn the language or get help / discuss some things with other people, especially online. I'm not dismissing the default formatter, it's obvious you still need one canonical representation of the code, but I don't think you should view it as "hiding" the formatting. In my view, it's more like opening a web page with one browser or another, or with one device or another. It always looks a bit different. Or maybe I have a theme configured on my main browser or whatever. I like to have my preferences, but if I have to look at the page from another browser, it's not a big deal either. The extra configuration might not be worth it or slightly inconvenient in some cases, but I doubt it's counter productive. The same way as I might prefer to read/write with a certain font or use this or that color palette. Maybe the takeaway is that code is more personal for some people than we like to generally admit. You are talking in a language and you want to be able to express yourself as comfortably as possible. I mean, we have had turing-complete and even "productive/decently ergonomic" languages for a while, and yet a lot of people keeps coming up with new languages, because they are much more than just a tool to get things working. We want to express ourselves as we "think", and formatting may be a small part of that, but it's still a part of it. [0] https://github.com/forest-lang/forest-compiler https://github.com/forest-lang/forest-compiler
- davnicwil 7y ago
  I definitely agree with most of this but I have to challenge the web browser analogy because that's a scenario where the concept of the view (visual, screen reader, etc) being interpreted from the textual representation is built in - as in, there is no end user who consumes the raw markup as-is. So different end users working with different views is a completey natural and expected thing. I guess that's what's missing to make this work for code. The raw code is intended as the final representation to the end user. Maybe what you'd need to make this work is to build in the concept of formatting to the source control itself, so all the way through the tooling you could 'render' the code as you'd like to see it, and do all operations on it using that view (including diffs, etc). Maybe sort of like you can with syntax highlighting, except with positional formatting instead.

mruts 7y ago

I mean, that’s the most common argument on why tabs are better the spaces. It’s also an argument I tend to be sympathetic too.