The question isn't what button you press. Nobody that advocates spaces over tabs is pressing the space bar n-times for each indentation.

It's a question of convenience over conceptual purity. Indenting by converting tab-key presses to spaces is more convenient since it preserves layout from editor to editor. Using tabs is more semantically correct (I guess).

In the end it really doesn't matter, as long as you are consistent.

Heh just a funny anecdote/coincidence

speaking of, what's the proper VIM way of doing this:

need to add quotes around the string to make it look like:

the cursor is at the first s. how do I do this in the fewest keystrokes? also for parentheses. without plugins, or if there is a very common one in use, which plugin?

I don't know any advanced way so I'd go:
after googling I think this is the easiest, and also works with the cursor anywhere on the word:
If its something you do frequently you can put a mapping in your .vimrc:
or just use a plugin:
https://github.com/tpope/vim-surround

I've seen people do it.

Sure, so have I. But those people aren't advocating using spaces over tabs. They simply don't know any better.

That's not the argument for tabs (at least from what I've seen in modern times and not on Silicon Valley). The argument for tabs is that each coder can have the code look the way THEY want it to via their personal tab settings.

The improper counter-argument for that is that alignment gets screwed up between people. One guy aligns a bunch of lines of code based on 4-space tabs, and for the next guy who likes his 3 space tabs, it looks screwy (because the first guy might align something with the line above it with tab-tab-tab-space (say 13 chars), and the 2nd guy with 3-space tabs would see it only 10 chars in).

The counter-counter-argument, and the reason why the first counter was incorrect, is that tabs should only be used for indentation, NOT alignment. Spaces should always be used for alignment. (So in the example from my last paragraph, the alignment would be performed with 13 spaces, looking the same on both machines). This can be clarified easily if desired. Now, manual alignment of structured code is preserved across settings, while simultaneously allowing different people to use their different tab settings.

The potentially valid counterpoint to tabs is if people don't correctly follow the rules I alluded to in my last paragraph. Then sure, spaces MIGHT end up being more successful. I'd say that's a case dependent decision, and independent of which is "theoretically" best.

The idea that you can use spaces for alignment and tabs for indentation seems fundamentally flawed, so I wonder if I'm missing something.

The alignment of a line should typically depends on the indentation of the lines above and below it.

These are all fine points, but I can't stress this enough:

None of it really matters. At all. The only thing that matters is consistency.

definitely install vim-surround. i use it constantly. in your case you'd type

ysw"

but it's totally general

ys <- invokes the plugin
some motion <- eg, "w" or "t." or whatever
the surrounding character <- quotes, single quotes, parents, braces, etc

I wasn't saying LL doesn't know any better, but if he didn't know any better...

I remember how confusing tools were to use when I first started. Granted, he is going to school, so I ought to assume he has better guidance than the misinformed proselytizing found on the interwebs.

Spaces matter with Python, and I think the language standards on this issue should be followed, regardless of anyone's beliefs on tabs -vs- spaces, amount of spaces for indents, or whatever. Personally, I just let emacs do whatever it is doing and don't put any thought into it.

****

IRT i3. It looks pretty cool. It works with every kind of window you can have on your computer, IE, browser on top-left, editor on bottom, terminal on left, etc?

I don't have the screen real-estate for it, but I'll definitely keep it in mind and keep on with ctl-tab for the time being.

Yes, you can split however you like, but most of the time I just fullscreen whatever I'm using anyways, so screen real estate isn't a big deal. Then I switch between the windows with alt+#. After a bit your fingers just know where your browser is, where your editor is, your terminal etc.

It's insanely fast as well on any hardware because it is so light-weight.

Yea you may be missing the idea here. I will demonstrate. Underscores will be "tabbed" spaces, so player 1 with 4 spaces/tab will represent a tab with '_'x4, and player 2 will use 3. Regular spaces will be represented with '.'.

Player 1 is writing some code. He has a big if statement that he wants to align. He does so like
Now, if player 1 had used tabs to align the "alice"s, player 2 would see the 2nd row aligned with the '(' instead of the 'a'. But with this technique, he sees the correct code as
So the key is to recognize there is a "base" indentation for the code block, and then spaces may be used on top.

Yes agreed

wow you're the first person i've seen suggest/use spaces and tabs, kuuudos

For a long time I've preferred this like

Which also neatly solves this problem. A reason I like this is that you can reorganize/add/remove conditions without having to conditionally add or remove a paren at the beginning or end. This is also moderately nicer on diffs because it's clearer to see what changed. Same goes for using trailing commas when allowed, etc.

It actually pains me that we store code in plain ascii, in some ways. Seems like some kind of under the covers semantic tag system could be nice. For example there are some conventions that drive me ****ing bonkers that don't seem to bother other people, such as spaces between function names and params, like

(I also hate the curly brace on the next line convention)

But pretty much every language is going to be tokenized by it's parser or compiler, seems like we could store code in an intermediate state and just display it to ourselves how we like.

Although that still leaves people who like to use spaces to line up with words kinda ****ed.

would any JS people here object to composition done like this,

I don't think the tab - indentation, space - alignment example given really fixes the issue for me.

The # of spaces being used for alignment is often going to be the person typing's preference for # of spaces in a tab. In cases like your example that would just irritate my OCD (which probably is ok). But there will be other cases where it would make code look ugly (imo).

Also, as a practical matter, any mixing of spaces + tabs is going to be a recipe for disaster. I don't believe you can train yourself to switch between the two seamlessly. It's an operation that gets repeated tens/hundreds of times a minute when typing. That's why spaces is the practical answer. You can set up an editor to fix the human error exactly the same for every developer.

The # of spaces for alignment is completely arbitrary. The number of characters in "if (" happens, to be 4, but we can repeat the example for a while loop:
Now we need 7 spaces for this alignment. I think it's very easy to keep track of because alignment is a very specific conscious thing in my mind, where as for everything else you're tabbing around happily without giving much thought.

I think you absolutely can train yourself to, it's not nearly as complicated as it seems like you're making it out to be. However, I definitely agree spaces is a safer bet.

Not if you use my method above (new line after the paren)

An example that comes to mind to me though, is that for a long time I preferred to indent SQL in a particular way that I thought was easier to read, and it definitely had tab/space problems.

This way all the stuff that is not SQL keywords is aligned. I dunno, I liked it. These days I don't bother, probably because I use a language that leans so heavily on specific indentation.

This is where we disagree. Sometimes it is, sometimes it isn't.

Oh, and we REALLY disagree here.

I still like this with sql and some other sql-like languages I use.

I also do things like:

One thing I do that I've found really helpful but I've never really seen done elsewhere in any of the programming books I've read or public code I've reviewed is, if I'm working with a file for input or output, I indent all lines of code between the file open command and the file close command, to visually remind me that the file is open at that time. Does anyone else do that?

How do you know you're not in a loop or a conditional? Seems like FPS.

Sure...