Live data from Hacker News

Tabs slower than spaces in Firefox

bugzilla.mozilla.org

111–120 of 129 posts

Re: Tabs slower than spaces in Firefox

#111
post #71

Earlier quoted context omitted.

Poe's law and all, I hope your comment isn't serious. The whole point was to highlight Richard's "neurotic" side. (It failed to convey it for me when his girlfriend started audibly indenting by hitting the spacebar 8 times... I'd go nuts, who wouldn't?) Also, plenty of geniuses use tabs :) the Linux kernel included. It obviously has no relation. (Seriously though, tabs are a matter of accessibility. https://leclan.ch…

If the tab people would reliably use tab for leading indent and space for further alignment, I'd be 100% on board. But what happens in practice is that the file ends up with a mish-mash of tabs and spaces throughout and the file is only legible if you set your tab stop to a specific setting, and sometimes not even then because different authors have used different tab stops for both indentation and alignment. At whic…

There is another alternative. At the risk of repeating what I've mentioned elsewhere in the thread, this is to not use column alignment at all.

Simply use indentation in the places where you might be tempted to start lining up columns.

It's really easy to use an alignment-free style. A good way to get in the habit is to code in a proportional font instead of monospaced. By doing that, you won't be able to use column alignment, and you'll naturally gravitate toward using indentation to represent the block structure of your code.

Re: Tabs slower than spaces in Firefox

#112

Earlier quoted context omitted.

> If the column-aligned way of writing a multiline function call or expression is such a good thing, why don't we also format blocks of statements this way: I don't see any reason not to. Your example is pretty ugly though, as it's not particularly aligned. What about: if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true ; } else { console.log( "no" ); this.that = false; } }

Why are you doing character-based right-alignment in a LTR script? It breaks with proportional fonts, and... well, if we wanted to right-align things in code, our non-document editor would probably support it by now, don't you think?

> Why are you doing character-based right-alignment in a LTR script?

It's not right-aligned, I've aligned the "." method accessors, ";" statement delimeters, etc. into the same column, and treated "else {" as a single token.

It would be even nicer to align the two pairs of statements more directly, but that ends up overflowing 80 characters, e.g.

    if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true ; }
                                   else { console.log( "no"  ); this.that = false; } }
> It breaks with proportional fonts

Proportional fonts break many "in-band" layout schemes; e.g. ASCII-art layout used in plaintext email. I think "out of band" layout schemes, like CSS, would be overkill for code layout; and certainly more effort to implement than making the editor manipulate ASTs instead of character streams.

Re: Tabs slower than spaces in Firefox

#113

Earlier quoted context omitted.

> So you're trying to dictate a coding style to make up for tabs' weaknesses? Not in the slightest. The disadvantages of column alignment have nothing to do with whether you use tabs or spaces. I don't recall for sure, but I think I was using spaces for indentation at the time that I stopped using column alignment. Column alignment has the same problems if you indent with spaces: it leads to excessive line length, it…

> If the column-aligned way of writing a multiline function call or expression is such a good thing, why don't we also format blocks of statements this way: I don't see any reason not to. Your example is pretty ugly though, as it's not particularly aligned. What about: if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true ; } else { console.log( "no" ); this.that = false; } }

Now that is an interesting approach! So you're lining up the dots? I like the creative thinking, even if I don't like the end result.

A couple of problems I see here:

What happens if you have more than one dot, like foo.bar.method()? Which dots do you line up?

And note that the else isn't aligned with its matching if.

I suppose another alternative would be to line things up like this:

  if( foo == bar ) { if( baz == moo ) { console.log( "yes" );
                                        this.that = true; }
                     else             { console.log( "no" );
                                        this.that = false; } }
Now the if and else line up, and so do the statements in the dependent blocks.

But with either of these aligned formats, I'm finding it pretty hard to visualize which if statement goes with which block of statements.

To me, this is one of the fundamental problems with column alignment: once you start doing it, it's too easy to start fiddling with all of the possible things you might align. And it really doesn't help the reader visualize the code structure except in the simplest cases.

Also, you're in for a maintenance headache when someone changes foo to moreMeaningfulName. Now what? Move everything farther to the right?

With an indentation-only format, you can change any of the variable/function names without breaking the formatting at all.

Re: Tabs slower than spaces in Firefox

#114
post #17
post #15

Earlier quoted context omitted.

This is interesting. Why do we use spaces anyway? I mean, really - what are the advantages spaces have over tabs? (I use spaces only because I try to follow common coding styles, like PEP 8, but I never gave it enough thought)

The reason is probably similar to why there's now top posting in emails. The support in editors is abysmal and doesn't work out of the box correctly for tabs (e.g. invisible whitespace). I've never seen an argument for spaces that would hold iff all editors would have sane defaults for programmers. Of course, it's also bad that some programmers can't configure their tools correctly, but that is a complete different i…

There's an even more conservative setting, which is "don't use alignment at all, use indentation only."

If you do that, all of these issues go away. You can use tabs or spaces for indentation, and it won't affect your formatting. You can reformat the code to a different number of spaces, or switch from spaces to tabs or vice versa, and your code will still be perfectly formatted.

A good way to learn and practice this style is to switch your editor to a proportional font. Now you won't be able to use column alignment, and without even working at it you'll naturally start to explore an alignment-free style.

I've had many programmers react in shock when they see I write code in a proportional font, but when you don't use alignment it stops mattering what font you use.

Re: Tabs slower than spaces in Firefox

#115
post #22

Earlier quoted context omitted.

I have to admit I always thought of that as an advantage of tabs, since they allow the viewer to set how much to indent the code, and doesn't force anyone to adapt to someone else's preferred style. I like it when a tab = 4 spaces, but you like it when a tab = 2 spaces. Cool, just set your editor accordingly.

Unfortunately, it also means that if the viewer hasn't or can't set the tab width, it may look awful. GitHub was using 8 spaces per tab by default, and my code looked ridiculous. Now GitHub checks .editorconfig for a default tab width, but it didn't used to.

It's certainly some progress that GitHub now follows .editorconfig! But now that they have the ability to render tabs with different numbers of spaces, I wish they could have changed the default to four spaces while they were at it. Aside from the Linux kernel, not too many people really like eight-column tabs.

I've always omitted the indent_size and tab_width settings from my .editorconfig files that specified tabs, because I wanted to let people view the code in their preferred default indentation size instead of one I specified.

(As I've mentioned too many times in this thread, I follow an indentation-only style with no column alignment, so you can view the code at any tab width without breaking the formatting.)

Now, just to make GitHub give a reasonable code listing, I'm having to add indent_size=4 to all my .editorconfig files. That's not a terrible thing, but I really would prefer to leave the choice up to the viewer instead of forcing 4-character tabs.

Re: Tabs slower than spaces in Firefox

#116

Earlier quoted context omitted.

Or just `set expandtab`...

That would be more like inoremap The request was: when I press two spaces, I want a tab character to be inputted. I agree that if you want `n` spaces when the tab key is pressed, you should use `expandtab` and `shiftwidth`.

Ah, quick/lazy reading. Sorry.

Of course now my question is why in the seven hells would you want that mapping??

Re: Tabs slower than spaces in Firefox

#118
post #10

I'm going to use this as fodder next time I get into an argument with someone about why spaces are better than tabs when writing code. Or maybe I've just been watching too much silicon valley...

I thought that was the most unrealistic thing this season: a supposedly genius programmer who loves tabs and hates spaces.

Shots fired!

Re: Tabs slower than spaces in Firefox

#119

Earlier quoted context omitted.

That would be more like inoremap The request was: when I press two spaces, I want a tab character to be inputted. I agree that if you want `n` spaces when the tab key is pressed, you should use `expandtab` and `shiftwidth`.

Ah, quick/lazy reading. Sorry. Of course now my question is why in the seven hells would you want that mapping??

The premise was that the tab key was broken.

Re: Tabs slower than spaces in Firefox

#120
post #15

Earlier quoted context omitted.

Poe's law and all, I hope your comment isn't serious. The whole point was to highlight Richard's "neurotic" side. (It failed to convey it for me when his girlfriend started audibly indenting by hitting the spacebar 8 times... I'd go nuts, who wouldn't?) Also, plenty of geniuses use tabs :) the Linux kernel included. It obviously has no relation. (Seriously though, tabs are a matter of accessibility. https://leclan.ch…

This is interesting. Why do we use spaces anyway? I mean, really - what are the advantages spaces have over tabs? (I use spaces only because I try to follow common coding styles, like PEP 8, but I never gave it enough thought)

AFAIR It is because a 30 years old rant in Usenet that defended spaces over tabs, but all their arguments were biased by the fact it was about LISP.

It's impossible to use anything but spaces in LISP without going mad, and the editors like emacs do a fantastic job formatting the s-expressions. So spaces are very superior to tabs for some languages.

For languages with a syntax similar to C, it doesn't matter, the rant was taken out of context, and the rest is history.

Whatever you use, make tabs and spaces visibles in your editor and never, ever, mix them up for indentation.

Post reply on HN