Tab width within Code tags

This	contains a tab
This    contains 4 spaces
But this        contains 8 spaces

Just testing. I used Notepad to create the above text

My suggestion is to change the option in your text editor to convert tabs to spaces because some people might use 8 spaces while others 4 or some other number. I've even seen just 2 spaces.

Perhaps have an option to set the tab stop explicitly in the code tags:

(code=c, tab=2)
#include <stdio.h>

int main ( void )
{
    puts ( "Hello, world!" );
    return 0;
}
(/code)

CSS 2 doesn't appear to have a tab-width property. The following are the properties that can be applied to text elements: http://www.w3schools.com/css/css_reference.asp#text

I know that if I use the option to replace tabs with 4 spaces (which I already do in Visual Studio), this problem would be over for my code. But we do not have control of the other user's editors. When they post codes with the tab character used for indenting, even code with a level 4 nesting can wrap unnecessarily. Sometimes I copy and paste the code to my own editor and replace tabs with 4 spaces to make the code readable, and was wondering if there was a quick fix. But if as Dani says that nothing can be done about it, well I guess we should grin and bear.

I believe it is a platform-specific setting ... i.e. Your OS/browser determines how many spaces per tab.

Gah, I hate when this happens! I was googling to see if there is a solution or workaround to this problem, only to find something that was specifically what I was looking for. I click on it and it ended up being this very thread.

I'm not going to try to pretend that I'm any sort of web programming expert, but couldn't you modify your parser to change tab characters into spaces? That way you could specify a manual tab width within the code tags, like Narue suggested.

That's a very brute force method that would undermine the purpose of tabs, screwing up more things than it fixes. For example, if tabs were to be converted into two spaces, the following:

echo "Hello World!";		// This is line one
echo "DaniWeb";			// This is line two
echo "Blah blah blah blah!";	// This is line three

Would be translated, without the poster's intent, into:

echo "Hello World!";  // This is line one
echo "DaniWeb";  // This is line two
echo "Blah blah blah blah!";  // This is line three

C'mon Dani, you can't fool me; I know you can do it. :) How hard would it be to make your parser calculate the number of spaces to insert to make it line up to the next tab stop?

Way more regex than I know. :)

I'll give you an exercise ...

Take one of your longer programs and stick it all into one string variable, where the \n character represents a hard return and the \n character represents a tab. Use regex on the string to figure out where a line starts and ends and then convert tabs to the correct number of spaces, based on the tab's position in the line. Be sure to accomidate extra long lines that word wrap to the next line line implicitely, in which case you'd need to figure out at exactly which character the line wraps. Make sure your parser is compatible with every programming language, including the likes of Scheme, ASM, etc.

Then convince me that it's all worth it just to fake tabs instead of using the platform/browser's default behaviour.

Then we'll talk :)

*starts coding* :P

The question is one of indentation, not embedded tabs. You only have to worry about the consecutive tabs at the beginning of a line:

$post_data =~ s/\n(\t+)/' ' x (tab_stop * length($1))/e;

Where post_data is your string and tab_stop is the number of desired spaces to replace tabs with.

I won't pretend that I understand more than the simplest regex line, but basically you're saying to convert tabs to spaces only when the tab is at the beginning of the line (i.e. when \t is directly following \n). That would break the following scenerio:

echo "Hello World!";
echo "Hello World!";
if ($blah)
{
	echo "My name is Dani";	// This is a comment
	echo "I love DaniWeb!";	// This is a comment
//	echo "My name is Dani";	// This is a comment
	echo "I love DaniWeb!";	// This is a comment
	// echo "DaniWeb!";	// This is a comment
}
echo "My name is Dani";
echo "Hello World!";
echo "My name is Dani";

Turning it into this:

echo "Hello World!";
echo "Hello World!";
if ($blah)
{
    echo "My name is Dani";	// This is a comment
    echo "I love DaniWeb!";	// This is a comment
//	echo "My name is Dani";	// This is a comment
    echo "I love DaniWeb!";	// This is a comment
// echo "DaniWeb!";	// This is a comment
}
echo "My name is Dani";
echo "Hello World!";
echo "My name is Dani";

With a tab of four spaces, which is what was suggested earlier in this thread, it coincidentally happened that lines 5, 6, and 8 have their echo statements followed by a \t, but the tab interval just happens to be one space later, making it look like it's nonexistant.

With much more complicated code, it would obviously be more screwy looking. When people start posting more complicated code from all different syntax languages, it will become more apparent sooner than later that their code isn't looking the way that they designed it to. I don't believe that a brute-force find and replace through someone else's code is the right way to go.

Weird ...

For some reason the tabstops hit at a different place in the Post Preview than when I actually submitted the post. Here's a screenie of what it looked like on my end, when doing a Post Preview.

You can replicate this behaviour by Quoting my text, removing the QUOTE bbcode, and then hitting the Preview Post button. This behaviour can also be witnessed by clicking on Advanced Reply and then scrolling down and looking at the Topic Review. You'll see exactly what I mean.

>basically you're saying to convert tabs to spaces only when the tab
>is at the beginning of the line (i.e. when \t is directly following \n)
Yep.

>That would break the following scenerio:
I'm not sure that finding edge cases is productive. If you have the option of turning off the adjustment or specifying the size, the problem becomes one of configuration rather than design. Also, I'm more inclined to deal with the common cases first and tweak for less common cases if they turn out to be a problem.

That said, why not test it out? IIRC, that's what we've done before with features you thought were grand but the rest of us were dubious about.

However, because I love to play both sides of an argument, changing the tab width still won't fix the wrapping issue because I nearly always use a 2 space indentation, and I still have to artificially break lines when posting to Daniweb. Worse, code that doesn't wrap in preview does wrap after being submitted, so I have to break much earlier than I normally would. I don't have numbers because it never bothered me enough to take the time.

I don't think this is a case of designing for the majority and then tweaking for the minority. Commenting out a line is something very common. I think that more than 50% of code will end up being broken in some way, shape, or form using this brute force method. A tab isn't just an easy way of typing out multiple spaces - they have different behaviour in more ways than one. You can see that my VERY simple program has three versions - The way I want it to look, the way Post Preview displays it, and the way it actually ended up in the post.

I'm also not keen on the idea of allowing people to specify how many spaces they want per tab. I think that leads to too much inconsistency.

Also, why do you have to artificially break lines?

This is line one.
This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line. This is one big line.
This is line two.
This is line three.

>Also, why do you have to artificially break lines?
Because I know how to wrap my own code better than some automated thingamajig.

I decided to visit some of the more recent code that's been posted and see just how many snippets would be killed if spaces automagically replaced tabs:

posted 50 minutes ago => http://www.daniweb.com/forums/thread116625.html => Code is written using a mix of indenting with spaces and tabs. Right now it matches up, but if the tabs were replaced, it no longer would.

posted one hour ago => http://www.daniweb.com/forums/thread116619.html => Frequent use of commenting out lines with // at the beginning of the line, before the \t character, would break this code the same way as in my example.

posted two hours ago => http://www.daniweb.com/forums/thread116609.html => A mix of comments preceding a line, after a couple of tabs, and inline, after a couple of tabs, would make comments look incredibly awkward and inconsistant.

As you can see, I don't have to go very far back to demonstrate how often things would be broken.

>As you can see, I don't have to go very far back to demonstrate how often things would be broken.
Nothing would be broken if what we have now remains the default, and only a special tag option changes the behavior. ;) Though since we have enough people posting code without any clue of how to structure it, I'm sure you could find a demonstration for dismissing pretty much any beautification feature.

Nothing would be broken if what we have now remains the default, and only a special tag option changes the behavior.

It would only be used by three people :) And I'm not sure of even that. You've said in the past you don't use (code=syntax), despite it's line numbering, because you're too lazy to type in more than just (code).

>You've said in the past you don't use I do now. Before it was because it didn't do what I wanted, but now it seems to work okay.[code=syntax]
I do now. Before it was because it didn't do what I wanted, but now it seems to work okay.

That's weird. I never changed its behaviour from when it was first introduced.

What I wanted might have changed. My preferences have been known to change over time.

http://www.daniweb.com/forums/post471579-13.html

I just played around with vBulletin. There's no way to specify more than one parameter for bbcode (such as ) without doing some *serious* hacking. Doable, but not convinced it's worth all the time and effort considering that it's a brute force style solution that is only going to work half the time and requires the code to already be well-formatted and have nothing commented out going in, and that only 5 people would be able to make use of it.

Then if we're to promote it as a new feature, I think it will just cause more confusion about how to use code tags. And the fact that no one has replied to this thread also says something about how many people care about it.

All in all, I agree that the default tabs are too big, but I don't think that converting them to spaces is the solution.[code=php;tab=2]) without doing some *serious* hacking. Doable, but not convinced it's worth all the time and effort considering that it's a brute force style solution that is only going to work half the time and requires the code to already be well-formatted and have nothing commented out going in, and that only 5 people would be able to make use of it.

Then if we're to promote it as a new feature, I think it will just cause more confusion about how to use code tags. And the fact that no one has replied to this thread also says something about how many people care about it.

All in all, I agree that the default tabs are too big, but I don't think that converting them to spaces is the solution.

IMO going all the way to convert tabs into spaces using some intelligent algorithm is way too much trouble than it's worth. It is basically the responsibility of the programmer posting the code to make sure that all tabs are converted to spaces and to follow the 80 column width limit if he wants to make sure his/her code looks good.

A good solution, if possible, would be to have 2 space tabs instead of what we have now.

Two spaces is too small - it makes it harder to line up brackets for really long code blocks.

>Two spaces is too small
One of my coworkers says the same thing. We have constant debates (playful, of course) about the merits of his four space tab style versus my two space tab style. It's playful because we both understand that both are equally readable.

>it makes it harder to line up brackets for really long code blocks.
First, if you have a long enough code block that it's an issue, you might want to think about refactoring. Second, while I've heard a lot of people say that before getting used to it, the complaint goes away shortly after they adopt two space tabs.

> Two spaces is too small - it makes it harder to line up brackets for really long code blocks.

Believe me, it's not. And I am pretty sure this is coming from you considering that you are used to 4 spaces for a tab. :-)

I am pretty sure that 2 space tabs would definitely bring down the indented mess that we get to deal everyday especially when dealing with tab-o-maniacs.