3 ms·

Well, this would be something that the IDE/mode you're using reflects. The indentation isn't "fixed", if you're inside a block it will be something, if it has a

Well, this would be something that the IDE/mode you're using reflects. The indentation isn't "fixed", if you're inside a block it will be something, if it has an open parens, then it might indent on the open parens, or two spaces after the parent line declaration start? I know what you mean because some modes (ie. in emacs, but I guess every other editor as well) sometimes will not be indenting how I think is correct, but this is not a problem with the "concept". I'm sure if we can cram artificial intelligence to give you the full word you're typing we ought to be able to make indentation by tabs work correctly across editors/machines/modes/plugins - and each "plugin" for whatever language can have its own idea of what is the right way (that would still be customisable - at least that's how it works with emacs). It's also a problem that only needs to be solved once per editor and then can be reutilised by whatever plugins using their own definition of what is the visual size of the tab and how it behaves on other semantic blocks of the language in use. I've moved to use formatters in languages that have a strict one so to not worry about this, I can even understand saying that just using spaces solves it, as it's the same everywhere - but essentially it mixes things - one is a question of visual representation that should be represented by a unit that a user can define (tab), the other is significant whitespace. In your example, with whitespaces, it's basically arbitrary - here it's 12spaces, next function where you multiline the arguments, it's `connect_more_14_chars(` so it will be 26 whitespace chars...

jcelerier 5y ago
> one is a question of visual representation that should be represented by a unit that a user can define (tab), where does this assumption come from ? > In your example, with whitespaces, it's basically arbitrary - here it's 12spaces, next function where you multiline the arguments, it's `connect_more_14_chars(` so it will be 26 whitespace chars... in practice it'll just be one key press as tools do the alignment. why would the number of whitespace chars matter at all ? what matters is that things are aligned.
- hnedeotes 5y ago
  > where does this assumption come from ? From the fact that with exception of languages with significant whitespace/tab it's a matter of visual representation: void foo() { connect(this, action, that, callback); } Perhaps I would prefer that my editor in this language, did this formatting. It doesn't change the meaning of the program. > in practice it'll just be one key press as tools do the alignment. why would the number of whitespace chars matter at all ? what matters is that things are aligned. This would be the same with tabs. But we go back to the same presentational aspect. If you prefer that it indents on the open parenthesis, and I that it indents on parent line start + 2 "visual" spaces we can't make an editor that covers both our preferences. With tabs, at least theoretically, we can, since the tab has no other meaning than an "indentation level" (which then translates into whatever it means "whitespace wise" for a given situation).

jcelerier 5y ago

> one is a question of visual representation that should be represented by a unit that a user can define (tab), where does this assumption come from ? > In your example, with whitespaces, it's basically arbitrary - here it's 12spaces, next function where you multiline the arguments, it's `connect_more_14_chars(` so it will be 26 whitespace chars... in practice it'll just be one key press as tools do the alignment. why would the number of whitespace chars matter at all ? what matters is that things are aligned.

hnedeotes 5y ago
> where does this assumption come from ? From the fact that with exception of languages with significant whitespace/tab it's a matter of visual representation: void foo() { connect(this, action, that, callback); } Perhaps I would prefer that my editor in this language, did this formatting. It doesn't change the meaning of the program. > in practice it'll just be one key press as tools do the alignment. why would the number of whitespace chars matter at all ? what matters is that things are aligned. This would be the same with tabs. But we go back to the same presentational aspect. If you prefer that it indents on the open parenthesis, and I that it indents on parent line start + 2 "visual" spaces we can't make an editor that covers both our preferences. With tabs, at least theoretically, we can, since the tab has no other meaning than an "indentation level" (which then translates into whatever it means "whitespace wise" for a given situation).