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 May 3 '11 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) – Kevin Vermeer May 3 '11 at 18:24
  • @Josh, you still have link to that SO question? – YOU May 3 '11 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 '11 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 '11 at 18:32
  • @Josh, Actually, its better for us at Code Golf with python? :P – YOU May 3 '11 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 '11 at 18:43
  • possible duplicate of How does The Editor Handle Tab Characters? – YOU May 3 '11 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 '11 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 '11 at 18:54
  • @YOU: thanks for the link. That's quite helpful. – jscs May 3 '11 at 18:56

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.

| improve this answer | |
  • 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 May 3 '11 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 '11 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 '11 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 '11 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 '11 at 18:58
  • I am as much anti-dead-kittens as I am anti-mixing-tabs-with-spaces. :) – jscs May 3 '11 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 '11 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 '11 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 '11 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 '11 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 '11 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 '11 at 15:17

You must log in to answer this question.

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