What is the tab width (number of spaces indented for a tab) within code tags? Is it 8? Is it possible to change it to 4? Since the code is wrapped for lines with length less than 80 characters, I think that it is a waste of space.
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.
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.
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?
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.
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.
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.
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.
