Indentation language is vague (Smart Tabs acceptable?)

[rye]

The wording on the spaces-as-indentation bullet is quite vague.

Use two spaces per indentation level (aka soft tabs). No hard tabs.^[link]

There is a distinction between "soft tabs", (i.e. spaces) "hard tabs", (i.e. \t is treated as a replacement for 8 space characters) and the semantic use case of tabs ("smart tabs"; i.e. \t is used for indentation and is used for alignment) which is not even mentioned in this style guide.

I'm of the mind that smart tabs is the semantic use of tabs. The main point of using tabs for indentation is to allow variation in indentation offset size; by this token tabs are still evil whenever they require you to know the tab size in advance, but as long as tab size doesn't affect code layout, they are permissible. Don't get me wrong; I like the idea of spaces as the surefire way to ensure your code renders correctly on all clients, but I also think that the 2-space indentation scheme is a bit too restrictive and arbitrary.

Personally, I use smart tabs in all of my code, and I am interested to see if this is considered a good compromise by other Rubyists. Furthermore, I am interested to hear if it is worthy of going into the Ruby Style Guide. It is not a popular scheme right now because many editors do not support it natively, (Emacs is the only editor I know of that has a package which supports it) but I do think that it is a good guideline to follow if you do end up choosing tabs.

To those who haven't seen the EmacsWiki page explaining this idea; I highly recommend giving it a quick look. I would propose something along the lines of the following change to the bullet point in question, if people think this is a good idea.

Use two spaces per indentation level (aka soft tabs) or use smart tabs (tabs for indentation, spaces for alignment). Don't use hard tabs.

Otherwise, I think this bullet point should be reworded to make it clear that tab characters should never be used, perhaps without mentioning hard tabs.

[bbatsov]

I think it's fine to mention the smart tabs in the guide and improve/extend the current wording. I wasn't familiar with the concept, but it certainly makes sense to me.

[bbatsov]

Emacs is the only editor I know of that has a package which supports it

What's the package, btw?

[rye]

@bbatsov, the Emacs package is smart-tabs-mode. It might not support ruby-mode natively—I'm not 100% sure, but it's a pretty easy configuration to get started. It just runs whenever both it and indent-tabs-mode are enabled.

I will probably PR the addition of smart tabs to this guide soon, then.

[bbatsov]

👍

[tom-lord]

(First time I've heard of this too) -- smart tabs seems like a sensible idea, if used consistently, but then so does hard tabs. It doesn't really matter what you use, so long as you're consistent.

In my opinion, the whole point of the style guide is to propose one, opinionated, style. Saying "smart tabs are fine too" defeats the purpose.

I think the current wording is fine. Smart tabs include hard tabs. The style guide says "no hard tabs"; ergo, smart tabs are not style guide compliant.

If you want to use smart tabs in your own code, then (as with everything else in this repo), that's perfectly OK; it's just not in agreement with this guide.

[tom-lord]

Adding an optional "hard tab mode" or "smart tab mode" to rubocop would be a good idea, I think. But not to the style guide. (Unless the community agrees that this is a better style than 2 space soft-tabs!)

[bbatsov]

Yeah, that's valid point. When you put it like this - the community certainly favours heavily "only spaces" for everything.

I wanted everything in the guide to be in line with

In my opinion, the whole point of the style guide is to propose one, opinionated, style. Saying "smart tabs are fine too" defeats the purpose.

But a few points were extremely contentious (e.g. single vs double quoted strings, spacing inside hashes, etc), that at some point I just decided to stop trying to waste my time pursuing this dream. :-)

[bbatsov]

I'm closing this ticket due to no recent activity. Feel free to re-open it if you ever come back to it.