Column number incorrect when using hard tabs

[MageLuingil]

The number being displayed for the cursor position is the character number, not the column number.

Observed behavior:

The issue can be easily demonstrated by using hard tabs instead of soft tabs:

Using spaces:

Using tabs:

Notice how the cursor after the tab character shows my position as "2". It's right, in a way -- I am at the second character on that line; but that doesn't give me any information on what column the cursor is on. Things get especially confusing when you reach the 80-character Preferred Line Length line, but the status bar shows that you're only on column 78 (or 75 (with two leading tabs), or 72...)

Expected behavior:

Most editors I've used do show the column number rather than the character number (respecting tabs as multi-column characters), and the setting for Cursor Position Format also says it should show the column number, not the character number:

Format for the cursor position status bar element, where %L is the line number and %C is the column number

Additional comments:

I think it would be nice to be able to use both character and column number in the format string (maybe add a %c for character number?), but that might be an enhancement for another day. At the very least, the existing column number value should be fixed to work with wide characters (such as the four-space tab character demonstrated above)

Tested (and screenshot) using: Atom version: 1.10.2 (safe mode) OS and version: Linux Mint 17.3

---

This same issue was reported back in January in the main atom issue tracker: atom/atom#10522

[50Wliu]

I think it would be nice to be able to use both character and column number in the format string (maybe add a %c for character number?)

As you said, the current behavior is technically correct, so I think adding a different formatting option would be the best way to proceed here.

/cc @atom/feedback

[maxbrunsfeld]

I'd be ok w/ switching to column number entirely.

[SteveAquino]

Personally I was surprised to find this behavior as I think most people care about column position, not number of characters. For example, this actually causes an erroneous error when using the https://atom.io/packages/fast-eslint plugin since it's (supposedly) based off the column number atom presents, which means that developer is probably not aware of this behavior either.

[SteveAquino]

Sorry, they're actually not erroneous errors - the line is longer than the max length, but the inconsistent column number makes it difficult to reduce the number of characters to the correct limit.

[jibsen]

I sometimes use the column number in the status bar to wrap comments in source files. I just noticed some of the lines are too long because of this.

[KXPN]

Just here to say this should be fixed, column count is an important way to keep things organized. Character count is an unexpected behavior

[emdash-ie]

I’m gonna look at taking this on :) The consensus seems to be that the current "column number" value should be changed from reporting the character position of the cursor to reporting the column position – is this correct?

[KXPN]

That's right. Thanks for looking into it, I may be trying Atom again as soon as this is fixed :)

[emdash-ie]

No problem! I’ve been wanting to contribute to atom for a while, and this is something that matters to me and seems pretty straightforward.

[Arcanemagus]

Note that since tabs have no set column width you'll need to respect the user's setting for how many columns they are worth. You wouldn't believe the number of bugs I've seen in linters (not Atom linter-* providers, the linters themselves) due to the authors making the mistake of thinking that tabs are anything more than a single character.

[emdash-ie]

Yes, of course :)

[smithtim]

The current behavior is very confusing! I thought the wrap-guide package was not working properly, because the line seemed to be appearing at column 75 instead of 80. I was just about to file a bug, when I noticed that tabs were distorting the column number. I hope this can be fixed soon!