19
\$\begingroup\$

Obviously this is personal preference when you're creating code on your own machine. However, since adding tabs to a text box is not (as far as I know) natively supported in most browsers. Three or four spaces would make editing/formatting questions and answers easier. This wouldn't need to be done on paste (though that would be nifty), but could be done at question/answer save time. Is something like that feasible?

For example:

    Two tabs
    Eight spaces

Appears in the editor like:

same as text above but two tabs text is spaced further to the right than eight spaces text

Which makes it annoying for lining up things for formatting. Maybe this is just nit-picky, but it would be nice to have some consistency.

EDIT

Allow me to make this clearer, there seems to be some confusion.

I clearly agree that mixing tabs and spaces is bad. This post is advocating for not having both. Since browsers typically only allow spaces as input, I'm saying we should automatically switch to spaces. Otherwise, if you want to edit code that's been pasted in with tabs, you can only add spaces, therefore mixing tabs and spaces. If the editor converted tabs to spaces, we'd never have mixed tabs and spaces.

\$\endgroup\$
  • \$\begingroup\$ you mean other than the currently implemented 4 spaces? you know inserting 4 spaces works exactly like a tab \$\endgroup\$ – Ali1S232 Apr 27 '12 at 20:40
  • \$\begingroup\$ Well not exactly like a tab, but yes I'm aware that I can use spaces. However, if I copy and paste my code that contains tabs, they remain tabs even when saved. This means if I wanted to easily change the formatting I'd have to convert it to spaces or edit it outside the browser with tabs and paste it in then. \$\endgroup\$ – MichaelHouse Apr 27 '12 at 20:44
  • \$\begingroup\$ still you can use spaces even if you are editing a code which is indented by tabs. but I agree with you saying it's easier if all of them were the same. \$\endgroup\$ – Ali1S232 Apr 27 '12 at 20:51
  • 3
    \$\begingroup\$ Upvoted for great justice. I'd like to see this. Formatting on-paste might be a better idea because otherwise any adjustments to your code in the editor might look completely different when you post it. \$\endgroup\$ – doppelgreener Apr 27 '12 at 23:56
  • \$\begingroup\$ some text editors support tab->Xspaces, and reverse such as notepad++. though I can see a possible issue having to copy over just to copy it again to SE \$\endgroup\$ – gardian06 May 4 '12 at 9:39
  • \$\begingroup\$ Yeah, it's easy with find replace is most text editors. And I've done with when editing other people's code, hence the request. \$\endgroup\$ – MichaelHouse May 4 '12 at 12:51
  • \$\begingroup\$ Much more clear now. \$\endgroup\$ – o0'. May 13 '12 at 15:27
  • \$\begingroup\$ So is the question 'Can we', or 'Should we'? Because the former is a technical question, the latter a question of policy. I'm not qualified to answer the 'can', but might be more inclined to answer the 'should' \$\endgroup\$ – MrCranky Aug 17 '13 at 10:43
  • \$\begingroup\$ @MrCranky I think it's fairly obvious that it can be technically done, with the easiest solution being at submission time. Feel free to read it as "should we". \$\endgroup\$ – MichaelHouse Aug 17 '13 at 13:42
-1
\$\begingroup\$

I like the initial idea, but at the same time. I am going to play some "devil's advocate".

first the system would have to know the difference between code, and text upon insert, and the system does not know this until after the tags have been processed (which for many users myself included not even entered until after the question has been written/copied) so the system would have to know what code looks like.

the only way to implement this cleanly would probably require users to use XML/HTML tags for example: (not that [ is equivalent to <, and ] is equivalent to > )

[Code]

//paste code here, and have tabs converted to 4 spaces

[/Code]

which are valid tags, but some users myself included don't use them, and just want to be able to paste in code, and have this kind of functionality there

the other thing that I could see is for those users that purposely format their code with tabs for spacing of comments to the right of code test (for clarity/explanation)

TYPE varName        // this var does ______

so that it is not confused as part of the code line just in case color formatting doesn't like it, and say that I just wanted 2 slashes.

but on the other hand I really would like something like this, and would appreciate it being implemented across all stackExchange sites, and probably the metas as well (code sometimes ends up on the meta sites)

\$\endgroup\$
  • 6
    \$\begingroup\$ "first the system would have to know the difference between code, and text upon insert, and the system does not know this until after the tags have been processed" This site doesn't use BBCode tags; it uses Markdown. You indent by four spaces or one tab for code. The system can understand immediately upon insert what's code or not. \$\endgroup\$ – doppelgreener Nov 10 '12 at 10:18
-1
\$\begingroup\$

Correct me if I'm wrong, but the user doesn't currently have control over the number of spaces used to represent a tab character in their code? Does Markdown assume exactly 4 spaces per tab, always? If someone has written code with an indent-width of 2 but with spaces instead of tabs in their code, does the system handle that properly?

Indenting is the easier of the two cases, because regardless of the tab width, the indents will look 'right'. But for mid-line tabs, you're mixing single characters with the tabs, and unless they happen to use the same tab width as the site / browser, then regardless of whether they're kept as tabs or converted to spaces, mid-line tabs will not line up correctly, without the ability to set tab width on a block by block basis, it probably won't look right.

I'd say converting tabs to spaces on pasting (or at some other convenient point) has definite merit, but I think it would have either have to be a) an optional feature, or b) allow setting what the tab width actually is. Otherwise people with a tab-width other than 4 are going to be continually annoyed that their code is being 'fixed' to use a different tab width, and not giving them the option to keep the tabs they wrote it with.

\$\endgroup\$
  • 1
    \$\begingroup\$ If people are mixing spaces and tabs in there code, I feel no remorse for their code not looking good when they move their code to a different format. \$\endgroup\$ – MichaelHouse Aug 18 '13 at 21:49
  • \$\begingroup\$ That's not what I'm saying at all. I'm pointing out that although indents will look right at any tab-width, mid-line tabs will only ever look right if the tab-width is the same as the user's. Fundamentally though, I think it's a good idea, since it removes any ambiguity, and it's probably no worse than the current system where it's difficult to add tabs to code after it's been pasted. But if it screws people with tabs set to 2 or 3 wide, then I think having the option to turn it off might be prudent. \$\endgroup\$ – MrCranky Aug 19 '13 at 6:56
  • \$\begingroup\$ People with tabs set to 2 or 3 wide deserve to be screwed with. :) (Speaking as somebody who worked for many years at a studio that mandated two-space tabs. ;) ) \$\endgroup\$ – Trevor Powell Aug 20 '13 at 1:05

You must log in to answer this question.

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