As someone who prefers tabs (I'm not looking to argue), I once asked Brendan Eich on Twitter why he prefers spaces. His answer was more thoughtful than I'd expected.
The tab key itself is hijacked by modern OS/UI behavior. It makes it complicated to actually type literal tab characters in certain contexts, particularly in the browser.
I still prefer tabs (and I'm a Go developer), but he is absolutely correct about that being a pain in the butt. For instance, try getting a tab character into the text area on Hacker News
Yeah but, even ones that don't use literal tab characters use the tab key to write code, right? RIGHT? Like, does he hit space N times?
I somewhat get the argument, but if you're writing code in the HN textarea you're doing something wrong (for code where tab/space matters anyways). Like, any code editor will use the tab key properly.
Though, it sills maddens me there's no somewhat universal tab-entry in OSes like we have with enter (somewhat because there's a mix of shift+enter, alt+enter and cmd+enter). All of shift/alt/ctrl tab are usually also hijacked.
> Yeah but, even ones that don't use literal tab characters use the tab key to write code, right? RIGHT? Like, does he hit space N times?
Now that I think about it, I think I haven't hit the tab key for indenting code in ages. I use cmd+] and cmd+[ to indent/unindent blocks of code in my default editor and doing so habitual for single lines now as well that I have 'unlearned' the tab key. For the few occasions I'm in a editor that does not have this keybinding I am actually hitting spacebar a few times as it is more predictable than whatever amount of spaces using the tab key would give me (or if it gives me a tab instead of spaces) and me having to dance around with the backspace key as well. Some editors I think use tab/shift-tab to indent/unindent blocks/lines of code, but not insert a tab. But then you are having 2 modes for the same key depending on the context.
Who "he"? I :set et (expand tabs) in vim :-P.
> it sills maddens me there's no somewhat universal tab-entry in OSes like we have with enter
That's a good point!
Were it up to me, I'd probably say something like: Ctrl+`, or maybe ` followed by escape, or something like that. Maybe one of the function keys? Eh...most if not all of those have been hijacked to mean various inane and stupid things too. :/
Hmm...oh! How about: Caps Lock+Shift ? I'm using an ergonomic keyboard, but I think the button press would still work pretty easily. I assume most styles of keyboard would have both, so it wouldn't lock people out if they are writing in a different language, either.
> Like, does he hit space N times?
Like the girl in Silicon Valley! [1]
I thought it was a bit funny that she was just hitting the space key over and over, but around the same time all my hobby programming was in TempleOS and I did the same thing. The indents were only 2 spaces though, and the tabs were eight wide.
Actually TempleOS' creator Terry Davis mixed tabs and spaces for the same argument stated in the Silicon Valley video, to save bytes. They're all rendered as spaces on the website but in the actual TempleOS code it's a mix of both. It means the indentation is really wonky on the Github mirrors (above 8 "spaces" deep), compare [2] and [3].
1. https://www.youtube.com/watch?v=oRva7UxGQDw
2. https://web.archive.org/web/20180906060812/https://templeos....
3. https://github.com/cia-foundation/TempleOS/blob/archive/Demo...
It might be reasonable to have a separate key for "tab" vs "next field", as well as separate key for "line break" vs "send". (But, tab and line break are not applicable for all contexts.)
However, it might also be reasonable to have a key or key combination (some programs use ^V) to enter control characters as data rather than as commands.
It might also be a consideration when designing a new computer (which does not have to be the same as existing ones); I had thought about such things and may make such a consideration.
Put it where the capslock key currently goes. Not sure what purpose it serves these days.
Its whole purpose is to be remapped as CTRL, as god intended.
It was a sad day (well, presumably pair of days) when Sun & Apple gave up that fight and moved caps lock into that position.
Also, Apple definitely had the nubbins correct (D and K) and foolishly surrendered that as well: they're easier to notice when they're under the wrong fingers. With them on F and J, if your hand is offset towards the outside you're forced to notice the absence of the nubs.
Wow I never thought about that, but it makes complete sense. I just tried shifting my hands "as if" the nubs were on D and K and wow, it should have been this way.
Oh well, just like caps lock can be remapped, so can my keycaps be swapped (perks of blank keyboards I guess), though it'd be even harder to use a keyboard that's not mine I guess.
Why the need for a third CTRL key, when the only backspace key is currently in Siberia?
If backspace is in Siberia, delete is in the Arctic. Wouldn't mind having easier access to that function.
Speak for yourself. I prefer SHIFT, I have too much muscle memory with CTRL+ZXCV and just pushing down CTRL down with an edge of my palm.
Is that how you do it? I have always used my left pinky. As I try it, unless I'm moving my hands off home row, both Ctrls feel just too far to be confident I'm hitting the right one (and not hitting the modifiers second in from the edges, and not hitting both). Maybe it's just my small hands!
In terms of ergonomics, the curled-left-thumb "Command" activation (it's where Alt is on a normal keyboard) is my favorite thing about the Mac key layout.
Depends.
Sometimes it's pinky on the CTRL and index on AZXCV ie the hand lower/closer to me.
Sometimes it's pushing CTRL with an edge of the hand and with the fingers on the ASDF to press AFRCVB.
Sometimes it's my hand on ESDF with run around in Zandronum and pushing CTRL with an edge of the hand to invoke 'invuseall'.
The main driver for moving SHIFT to CAPSLOCK is what SHIFT is used way more common than CTRL and with my big hands it gets quite uncomfortable for my pinky to used too much in an awkward shrimp mode.
NB on a non-laptop keyboards I flip both Windows/Super keycaps upside-down, helps a bit.
> as well as separate key for "line break" vs "send"
There is: Return vs. Enter. Sadly there are not many OSs and programs that honor this. I'm personally also sad about Scroll Lock. It would be useful, some programs even reinvent it, on Firefox it's basically F7.
The fact that most people think the Tab key is the correct choice is a perfect example of why it was not.
It had a purpose, and it got hijacked and made its actual purpose more difficult to use.
It's not dissimilar to Apples initial Touch Bar and then removing the Escape key.
Average user might never use that key; average developer doesn't got long without using that key for its purpose.
When you type a table on a typewriter you use the tab to advance to the next column (how many you have depends on the typewriter - you often had margins and one or two tabs). In typewriters, tab doesn’t have a specific width and you don’t have tab stops at every 8 columns. At least on the ones I have here.
Control-shift-u, 9, space/enter, works on most Linux systems.
To explain: control-shift-u allows entering a Unicode character by its hexadecimal code. This presumably depends on the Input Method Editor (IME) in use, which is something I've never fully understood, but this seems to work widely across different desktop environments (Xfce, KDE) and display servers (Xorg, Wayland).
Non english speaker trying to wrap my head around what Brendan said to you.
I was once told that the tab key can be represented in different ways on different systems, and that's why spaces are safer because they're always represented the same.
Is that what Brendan was trying to say?
Literally try entering a "tab" character in a Hacker News reply. For me in Safari, it changes the focus to the "reply" button.
It's literally difficult to enter a "tab" character into many text entry fields and dialogs and applications, because it's used so often as a navigation key.
It is Control-Q Control-I. Control-Q is the quoted insert function, and Control-I is the traditional teletype way of typing a tab 0x09 (just like Control-C in a terminal results in 0x03 when not in a cooked mode).
I only found this because I am an Emacs user and I instinctively tried Control-Q first (because many other key bindings like C-f or C-b work). The Control-I bit is a guess that worked. I cannot imagine a non-technical user knowing how to insert a tab character in Safari.
I can’t find the tab key on my phone. Please advise.
> I was once told that the tab key can be represented in different ways on different systems, and that's why spaces are safer because they're always represented the same.
The main counter argument is that users have different preferences for the amount of indentation, so giving them control over that, just as they (nowadays) have control over the font used and window width, is a good idea.
The tongue-in-cheek counter argument is that fixed-width spaces are preferable over ‘normal’ spaces. They also give you more control over indentation, allowing, for example, mixing usage of THREE-PER-EM SPACE (https://unicode-explorer.com/c/2004) for indentation with FIGURE SPACE (https://unicode-explorer.com/c/2007) for right-aligning numbers.
No, the point was that pressing the Tab key often does something else than inserts the tab character. Moves focus to the next input field, for example.
Tab key is both a control character moving the cursor to the next input and also an input representing the tab character as you see in a text editor.
Now that im thinking about it I’m convinced capslock would have been superior next field key and alt+capslock to be used for toggling capslock. But it’s not obvious to me capslock [e: must be] seen by the OS. It could be changed on the keyboards themselves.
It definitely is visible, OS login screens usually warn you if caps lock is on when typing password
Thanks for the correction. I understand it is seen but wonder if it was in keyboard only in the past.
I don't think that would work, as capslock should only affect the letter keys (not e.g. turn "1" into "!") and the keyboard doesn't know which those keys are, as it depends on the layout configured in the OS.
Also, some layouts use shift lock (so actually turning 1 into !) instead of caps lock
No, it's that it's extremely challenging to insert a literal tab character into anything resembling a web form.
You can configure your editor so that pressing the tab key inserts a tab character. Good luck with a web browser, or a UI where tab moves focus to the next control. The space bar basically always inserts a space character.
> The space bar basically always inserts a space character.
Except when it does page forward.
No he's saying if you're trying to write code in an edit box in a web browser (for example) and you press tab, instead of inserting a tab character it will move the focus to the next input field.
Bullshit reasoning though, because even people who use spaces for indentation don't do it by hammering the space bar - they also press the tab key. And of course in modern browsers we can give tab the expected behaviour.
The only logic I've ever heard for using spaces for indentation that actually makes sense and I vaguely agree with, is that lots of programmers do not give a shit about formatting code and even using spaces properly is often a bit too much for them.
That doesn't matter so much if you have an autoformatter though, so with the exception of Go I don't know why modern languages with widely used autoformatters don't use tabs.
[dead]
Brendan Eich was making a point about the tab key also being used to switch to different text fields and buttons. This makes it difficult to type in certain applications. A space doesn't have that issue.
About your point of tab being represented different on different systems: It will always be ascii 9, how it's draw does differ between text editors but I consider that one of it's strengths for programming. Everyone can configure what an indent looks like for them, it makes reading code easier.
Having a non-standard size is exactly the reason the tab character (not the key) is unusable. If you accidentally get some space indenting anywhere in the same project as tabs, then it'll be misaligned on someone's editor and they'll "fix" it, making it misaligned on someone else's. Trying to never use space indenting is impossible. Never copy and paste from anywhere else, never manually align multi-line statements, never align comments with code, etc.
IMHO, issues with formating, like the ones you describe, should be cought by a linter. Or even better yet, enforce format-on-save in all editors your team uses and have it automatically re-indent and reformat the code so what indentation it was originally indented with irrelevant. I think this approach would work, but I tend to work on files < 10k LoC, it might get annoyingly slow past that.
I didn't even consider that, I just assumed we're talking about text editors.
But yeah I guess, that's another argument against getting accustomed to tabs for indentation.
Little irritates me more than logging into a new system, opening up code in vim, and witnessing the insanity of tabs-as-8-spaces
For me, it's not until that file is retrieved for local use where I have to deal with this. If it was born remotely and only used remotely with the same settings, I never notice it. But yeah, I hate it with the passion that raises my temp to that of a thousand suns.
The solution is to exterminate tabs, not hope everybody's settings are the same. I only code in editors that auto-convert tabs to spaces.
BTW, Douglas Crockford had an interesting argument in favour of spaces, see https://www.youtube.com/watch?v=En8Ubs2k1O8
What of Crockford's argument interested you?
The typewriter history was irrelevant.
He said people argued how wide should a tab be. And this caused misery. But almost all tabs advocates said tabs should be any width you want in my experience. And spaces advocates argued how many spaces should indentation be.
He said there was no value in the conflict. There is value in accessibility.[1][2]
He said tabs could be eliminated and spaces could not. Spaces could be eliminated for indentation. And indentation could replace alignment with initial spaces.[3]
[1] https://news.ycombinator.com/item?id=20341354
[2] https://news.ycombinator.com/item?id=20381027
[3] https://news.ycombinator.com/item?id=20341788
> What of Crockford's argument interested you?
That tabs can be eliminated but spaces not. The rest is incidental to this idea.
An action could be made is not an argument it should be made. You could eliminate ' with " and escape sequences in some languages.
[flagged]
There's also the fact that no one seems to have tab stops set the same way.
That's a feature, not a bug.
As far as I'm concerned, it's a feature when the viewer controls the number of spaces per tab, it's a bug when someone else does (as is often the case online via css `tab-size`).
You want source code indentation to be random on different machines? I guess. That would make me crazy.
Yes. That is the point.
I can have my tabs look the way I like them. You can have your tabs look the way you like them.
Until you open your code somewhere where you can’t configure the tab size, such as on SourceHut or other forges.
Or if you have your tabs set at 3 and I have mine set to 4 and you want to indent something 6 characters so you enter two tabs. When the code gets back to me it's indented 8 spaces and nothing lines up anymore. So I change it to one tab and 2 spaces and when it gets back to you it's indented 5 spaces instead of 6, so you change it back to two tabs and we spend our time indenting code to make it readable instead of doing our jobs
We had such vicious battles at Convex we wrote a tool that "canonicalized" code before it was checked in and then "decanonicalized" after checking out. There were issues with comments, but they were manageable.
It’s not “random”, it’s whatever you’ve configured it to on your machine. Your choice of (e.g.) 3 spaces per tab shouldn’t be forced onto me if I prefer (e.g.) 4 spaces per tab. As long as you’re on your machine, you’ll see exactly the amount of code indentation you prefer - not something “random”. On someone else’s machine, well, that’s up to their preference, and it’s hard to complain about how someone else has their machine setup.
TL;DR: This is a feature, not a bug
So when things don't line up... That's a feature? The reason I use indentation is so there's consistency between lines. When you use spaces, the semantics of indentation are maintained. If you don't like the indentation settings, just change them in the v-linter.
Tabs represent a logical indent, not a physical one, you choose how the mapping to physical indent is.
> So when things don't line up
Why would things ever not line up? There is 1/2 tabs indentation and it shows up as 1,3,7,8,42/2,6,14,16,84 indentation however you like it.
I've ran into an elusive bug in VSCode where sometimes pressing tag moves focus to the next focusable instead of adding a tab/spaces. It's infuriating, and the only solution is restarting VSCode.
CTRL+I?
[dead]