1. General
  2. Pomysły
+70

Indentation level setting (different from tab size)

David Capello 13 lat temu • Ostatnio zmodyfikowane przez User______ 8 lat temu • 10
Add some options to specify the indentation level (which is different from tab_size):
  • indentation_size/indent_level (integer): number of spaces to use to indent code, which is not the same as "tab_size"
  • compress_spaces_with_tabs_on_indentation (boolean): to specify that spaces should be converted to tabs when you reach a certain level of indentation (e.g. 8 spaces compressed to 1 tab if tab_size=8)
+10
Seth LaForge 13 lat temu
I'm mystified why people would vote against this.  I think there may be a bit of a philosophical culture clash in action.  Tabs are a bit a religious issue.

In the UNIX world, I'd say the dominant view is that tabs should always be aligned to 8 columns.  Making any other assumption results in all kinds of breakage and awkwardness when it comes to using a shell: terminals all assume 8-column tabs, and if your source code assumes some other tab width, tools like diff and such are going to mangle your indentation.  At the same time, most projects (Linux kernel excepted) feel that 8-column indents are excessive, so in practice you need to use spaces for indentation.  Some projects then allow 8-column tabs as a sort of encoding optimization, and others forbid tabs entirely.  If tabs are allowed, then you really need separate settings for tab stops (":set ts=N" in vi) and indentation (":set sw=N" in vi).

As support for my claim that this is a reasonably common world-view: Google's internal coding standard for C++ specifies 2-column indents, 8-column tab stops, and recommends against tab characters, but they sneak into the code anyway.

I think in the Windows world there is no hard standard for tab stops and nothing to enforce one, since console usage is much more rare than in UNIX.  Thus it's a common Windows philosophy to conflate tabs and indentation.

In any case, I think Sublime 2 needs to implement a setting for indentation width independent of tab stops in order to be taken seriously by people and shops which subscribe to the UNIX philosophy.
Joel Thornton 13 lat temu
Personally, I like using the "translate_tabs_to_spaces" option, thereby always saving files with no tab characters in them. That way, anyone who views my code sees the indentation levels I originally intended regardless of their tab width setting. Combined with ST2's quite accurate "guess indentation width from buffer" feature, I rarely run into issues with indentation, even when looking at other folks' code.

Another nice feature I've just come across is Reindent Lines (Edit->Line->Reindent Lines or accessed via Ctrl+Shift+P), which overall does an admirable job of fixing a file's/selection's indentation to match my chosen indent width.
+8
Alexander Nalivayko 12 lat temu
I am absolutely agree with previous comment.
This is a bad practice to change tab width to any value. It should be 8 chars long. Period.
You should separate indent stop and tab stop as separate settings.
Imagine we use both tabs and spaces to indent.
If John uses 8-column tab and uses 4-column indents then his code will look like this:
---
     1st indent with 4 spaces
        2nd indent with 1 tab (his editor settings set to replace spaces with tabs)
---
Now I open this text in awesome ST2 :)
My settings are:
---
// The number of spaces a tab is considered equal to
// Because I want 4-column indent
"tab_size": 4,
---

And what do i see? This text:
---
    1st indent with 4 spaces
    2nd indent with 1 tab (Bah!)
---

Actually solution is pretty straightforward: add setting
"indent_size": 4,
and you are done (i hope).
Only this missing feature stops me from using ST2 and purchase it (I have never imagined i would PURCHASE text editor for Linux with its tons of FREE editors).
Currently I use Kate under Ubuntu.
Actually I attach image with Kate indentation settings just to be more specific on this issue.

+6
Jeff Petkau 12 lat temu
+1. Unfortunately there are many existing codebases where tab size != indent size, and as-is, Sublime makes a mess of these files.


I see all of these on a regular basis:

A. Indent is 2 or 4 columns, no hard tabs allowed

B. Indent is 2 or 4 columns (mixed tabs and spaces), hard tabs are 8 spaces (common on Unix)

C. Indent is one hard tab, hard tab is 4 spaces (common on Windows)

D. Indent is one hard tab, make it whatever size you want

(Regardless of what the style "should" be, requesting that an entire project change their indentation because my editor doesn't support it has not gone over well in the past.)

Any word on when/whether this is likely to get implemented?

Brandon Fosdick 12 lat temu
ST2's inability to independently set tab size and indentation size is the one thing keeping me on the free version. It's forcing me to switch back to Xcode more often than I'd like.
Michael Krueger 11 lat temu

Many coding conventions call for different values for "unit of indentation" and "tab character size"; for example, the Java conventions state that a unit of indentation is four spaces, but tabs must be set at eight spaces:


http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-136091.html#262

Brandon Fosdick 11 lat temu

Anyone know if this is fixed in ST3?

Michael Krueger 11 lat temu
I am using Sublime Text 3, and I could not find the feature; if it is implemented, it is not documented.


Brandon Fosdick 11 lat temu

That's a shame. Thanks for looking into it.

+1
User______ 8 lat temu

A little bit late but has this been implemented yet? This is the last holdout before I am ready to switch... Current codebase is inconsistant and forcing indent to match tab spacing is a deal breaker

Customer support service by UserEcho