161–170 of 238 posts
Earlier quoted context omitted.
But don't fixed width fonts, which many consider the best for code, mean fixed width spaces too?
If that were the case tabs would be fixed width too. But they're not. There's no fundamental reason tabs have to be the only variable-width character.
Tabs are the modern choice, because you can then configure your editor so that for every tab character, it calls an LLM with the buffer contents up to that point, with instructions to generate an appropriate number of spaces that can then be substituted in. You might be thinking 2, 4, or 8, but the LLM will give you the contextually-correct answer.
Earlier quoted context omitted.
Disallowing /[^\t]\t/ and /^ / is a good start.
These regexes don't solve what I think is one of the major common problems/complaints though: using extra tabs past the logical indent point as a shortcut to avoid typing so many spaces for alignment purposes. To take this example from a sibling post: if (foo) { » frobnicate(bar, » ...........baz); } Many people will wind up doing this: if (foo) { » frobnicate(bar, » » » ...baz); } And then your alignment is all mess…
For example, I considered writing a small Awk program to check C code in response to another poster’s complaint about lack of tooling, but then quickly came to the conclusion that, with C’s insistence that (say) /??/* is a valid comment starter, getting this exactly correct probably does need an actual lexer that would go character by character. That sounded like it wouldn’t fit in an HN comment, so I stopped there.
(That said, that’s as far as you’d need to go in the majority of cases. A dishonorable mention is warranted for languages that use the same character as an operator and a paired delimiter simultaneously, that is C++, Java, C#, TypeScript, and Rust with their abuse of the less-than and greater-than symbols, because that would in fact require a parser. In C++ especially, you’ll need full semantic analysis with template expansion, name resolution, and consteval evaluation. Because C++.)
Yet you probably don’t actually need to be that accurate, do you? The majority of syntax highlighters aren’t, and they are still useful. You can usually afford to say that code that perverse deserves to lose, and in return I expect you should be able to gain a fair amount of language independence, which could be worth the tradeoff.
So instead of checking if things are aligned with what they should be, you would just check they are aligned with something, like a left word boundary preceded by a delimiter, and so on. I can already see unpleasant corner cases after thinking about it for a few minutes, but it doesn’t look hellish yet, it looks something like you could experiment with over a weekend to see if it was viable.
The war is mostly over because regardless of it you use tabs or spaces, the many modern languages use a code formatter and reformat to whatever is common. Languages that go with tabs are also now routinely mixing it with spaces for visual alignment and assume a certain tab width for total visual width enforcement. On the other hand editors often now handle spaces as if they are tabs, even for cursor movement. So well…
No one who uses tabs would ever assume a certain tab width for visual alignment. What do you base that slanderous statement on? I've also never heard anyone argue that someone else should configure some different tab width, is there a specific language ecosystem you were in that had these insane takes?
> Tabs are 8 characters, and thus indentations are also 8 characters.
Yes, tabs are used for alignment as well.
To quote the OpenBSD style guide:
> Indentation is an 8 character tab.
The GTK source code uses tabs when the number of spaces for indentation >=8. This goes against their coding-style document, but if you don't have tabs set to 8 you'll find the indentation broken.
git is the same: although it prescribes tabs if you don't set the width to 8 you'll find broken alignment everywhere.
The point of the "tab" option is that there is no consensus on the number of spaces to use -- so by using tab, one uses a single character, and allows the developer to determine screen spacing to their comfort. "Tab" being a live option is a symptom of the war-never-over in absolute spacing degree -- since different people have different eye-sight, eye-strain, etc. constraints, different linguistic familiarities, cod…
btw, it still ignores it at times.
Of course, long back, these are also the first things I did so the team can reduce fights and let them choose their own tab-to-space preferences. The other thing was to set up `.gitattributes`[2] early on, specially for those on Windows, to commit the correct attribution when pushing to git.
Earlier quoted context omitted.
which editor does that? space width is defined by the font, and normally you use monospace fonts. i am unfamiliar with any editor that allows you to choose a different font for spaces. besides, it would only work for indents, it would mess up any alignment of code into columns.
None, but it's clearly possible to add since such handling is already present for tabs in almost any editor. I merely mean that there's no technical restriction.
In the 90s, when I used various text editors like Ultraedit, Nedit, Pico, Nano, Vi, and my co-workers used Dreamweaver, Visual C++, Visual Basic, NetBeans I was in the "TABs are superior" camp but only for the initial indention of code blocks. But somewhere along the way, editors added features that let you see invisibles, and let you set up smart tabs so that you could hit tab, but it would interpolate 4 spaces (or…
Earlier quoted context omitted.
I’d say that one’s approaching resolution, too. And 4 has won.
According to the table in the article there are more languages with a recommended value of 2 than languages with 4. I'm using 2 for Ruby and 4 for Python. I don't remember what I'm using for JavaScript, maybe the same value of the main language of the project.
Not sure why people are so obsessed with having power of 2 spaces, can anyone explain that? Why argue over 2 vs 4 when you can have 3 for everything? I think 4 is better than 2 since 2 is too hard to track, but 3 obviously is better than 4.