I've found these two Meta questions:

Make WMD (Wiki Mark Down) convert tabs to spaces
Text editor on trilogy sites really SHOULD convert TABs to spaces!

both of which state that the editor is supposed to convert tab characters to spaces in code blocks, but that does not seem to be the case. Am I crazy? Am I misunderstanding?

This is one of the most mind-numbing editing tasks, and it would be nice for it to be automated by the system. I copy-pasted this from a recent SO question to demonstrate:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

static NSString *MyIdentifier = @"MyIdentifier";
MyIdentifier = @"tblCellView";
NSString *offendersImagePath = [self applicationDocumentsDirectory];
//NSLog(@"%@", dbPath);
offendersImagePath=[offendersImagePath stringByAppendingPathComponent:@"Images"];
^Tab characters at the beginning of all the above lines; they have
not been converted and they are not displayed indented.
  • They look like they are in code formatting, and all of them have 4 spaces in front of them.
    – Grace Note StaffMod
    May 3, 2011 at 18:23
  • Josh, when I copy-paste (from the "edit" mode, of course) into Notepad++, there are no tabs - just 4 spaces. Is this the behavior you observe? What behavior do you expect? (I expected to see 4 spaces, tab character, then the text from your explanation) May 3, 2011 at 18:24
  • @Josh, you still have link to that SO question?
    – YOU
    May 3, 2011 at 18:27
  • @Grace @reem Thanks for your replies. I may have managed to screw up the copy-paste; when I edited my question just now I found that there were four spaces in front of every line. I re-pasted and verified that there are tab characters. Could this be a browser issue? Does the tab->space conversion happen after the post is made? I have seen any number of posts which had tab characters beginning lines in code blocks, which display un-indented. Just as an example, here is the question from which I copy-pasted: stackoverflow.com/questions/5870367 @YOU
    – jscs
    May 3, 2011 at 18:30
  • @reemrevnivek: Specifically, I am seeing one tab character at the beginning of each line when editing the post, and no indentation when the post is displayed. Sorry that wasn't clear.
    – jscs
    May 3, 2011 at 18:32
  • @Josh, Actually, its better for us at Code Golf with python? :P
    – YOU
    May 3, 2011 at 18:36
  • See my answer: the Markdown renderers appear to be handling tabs appropriately (which is to say, a tab equates to four spaces for indentation and code-block delimiting purposes). What would you expect to happen?
    – Shog9
    May 3, 2011 at 18:43
  • possible duplicate of How does The Editor Handle Tab Characters?
    – YOU
    May 3, 2011 at 18:49
  • @Shog9, Jeff said that once the post hit the server, tab will convert to spaces, so tab shouldn't be exist on revisions/view source/edit according to that. But looks like its changed now.
    – YOU
    May 3, 2011 at 18:52
  • 1
    @YOU: he said the Markdown renderer (MarkdownSharp) does the conversion. The renderer is what... renders HTML from the Markdown. It doesn't modify the input.
    – Shog9
    May 3, 2011 at 18:54
  • @YOU: thanks for the link. That's quite helpful.
    – jscs
    May 3, 2011 at 18:56

1 Answer 1


According to this answer:

The server-side markdown parser does normalize tabs to spaces.

So let's test this: here's a tabby cat...

    sez, "Meow"

...and here's the HTML rendered:

    sez, "Meow"

...correctly indented, with tabs converted to spaces. It appears that both the server and client-side Markdown renderers perform the same conversion, as the preview looks identical to the final page. The original text, tabs intact, is visible when editing, or via view source from the revision history.

  • You're right, they both convert tabs to spaces; unfortunately they don't do it in the same way; Showdown's detabbing is quite broken. But that's a different issue.
    – balpha Staff
    May 3, 2011 at 18:51
  • Okay, I understand what's happening now. I was incorrect in my expectations. I was expecting the tab character to count in the context of the code block. If four spaces starts a code block, then then tab characters on lines after that indent starting from the "defined" indentation of four spaces. I realize that probably sounds absurd (it sort of does to me too now). I think the 8-character tabs in my browser were confusing me. Thanks for your time.
    – jscs
    May 3, 2011 at 18:55
  • 2
    @balpha: if you're mixing tabs and spaces, you're a fence-sitter, a luke-warm indenter, a man with no conviction. There's just no helping such a person...
    – Shog9
    May 3, 2011 at 18:57
  • Although, the question remains (different question) of why the "auto-code-formatting brackets" don't add four spaces to lines that already start with tabs in the case where you select a big block of code (which someone else posted!) that uses tabs instead of spaces.
    – jscs
    May 3, 2011 at 18:57
  • 1
    @Josh: no problem - it is a bit confusing I suppose, although this certainly beats the old behavior (tabs == dead kittens). As for why they don't expand tabs to eight spaces, I'd imagine because eight-space indentation looks pretty horrible in the fixed-width code blocks, and would end up being edited anyway.
    – Shog9
    May 3, 2011 at 18:58
  • I am as much anti-dead-kittens as I am anti-mixing-tabs-with-spaces. :)
    – jscs
    May 3, 2011 at 18:59
  • In a case such as this, the code inside the method should be indented one level. So if the original text of the code contains method header at indent 0, method body indent 1 (using tabs), and I select that text and hit the code-formatting button here on SO, it seems reasonable to me that all the lines in the selected text should be modified the same way, i.e., adding four space characters. I certainly wouldn't want to see 8-character indentation for displayed code either, but the behavior seems strange. If it starts bothering me enough, I guess I'll ask another question on Meta about it.
    – jscs
    May 3, 2011 at 19:06
  • 3
    @Josh: Oh, now I see what you're talking about! Yes, the indentation tool in the editor appears to be largely unaware of tabs.
    – Shog9
    May 3, 2011 at 19:25
  • But, Shog9, then no [status-completed] for Text editor on trilogy sites really SHOULD convert TABs to spaces!, right? Not sure why @Josh accepted this, so maybe I don't understand, but: care to remove that tag again?
    – Arjan
    May 4, 2011 at 6:00
  • @Arjan: accepted because Shog9 explained what I was misunderstanding. The thing we were talking about in the last two comments is a separate issue.
    – jscs
    May 4, 2011 at 7:44
  • 1
    Oh, @Josh, so the link to Text editor on trilogy sites really SHOULD convert TABs to spaces! was incidental; I figured it was the reason for your question but now I see Shog9 tagged that [status-completed] after you asked, not before. Still: I don't think the new tag for that question is correct. (It could be [status-declined] of course, but [status-completed] suggests tabs are now converted to spaces in the editor, as requested in that question. But they are not.)
    – Arjan
    May 4, 2011 at 7:58
  • @Arjan: quoting from that feature-request, "I think the text editor on the trilogy sites URGENTLY needs to convert TABs that users paste in to spaces, if it cannot handle tabs properly" - my understanding is that the text editor (well, the Markdown renderers at least) do handle tabs now. Whether they're handled "properly" or not is certainly up for discussion... but tab-indented code no longer looks terrible when rendered, so there should be less of a pressing need to spend lots of time re-indenting code posted by tab-users, which was the core of the complaint.
    – Shog9
    May 4, 2011 at 15:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .