[quietbritishjim]

> so by using tab, one ... allows the developer to determine screen spacing to their comfort

(Allow me to reply to this age-old argument with the age-old counter argument...)

But you also have to decide at what point to hard wrap each line based on a max line length, and you can only do that based on some choice of tab size. Anyone with a different tab size preference would see the right column wandering depending on indentation level. This invalidates the only advantage of tabs (assuming file size is no longer a concern).

A common retort is that each reader's auto format (or soft wrapping) can sort out the wrapping. But if each coder is going to reformat the code anyway then they get the benefit of choosing their own indentation level regardless of tabs vs spaces.

[JohnFen]

> But you also have to decide at what point to hard wrap each line based on a max line length

I think that you should not be doing this, for the same reason that you should use tabs. It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.

But all of this sort of thing is pointless debate these days, when it's pretty fast and easy to preprocess the files to match your preferences prior to editing.

[eurleif]

>It allows the user to select whichever hard wrap point (if any -- I generally choose to not have one) they prefer.

And then have merge conflicts between people who set different hard wrap points? Did you mean to say soft wrap point?

[JohnFen]

Yes, my mistake.

[1718627440]

But you don't hard wrap at exactly the max line length anyway. You wrap at the somewhere sensible near the max line length. This is much more tolerable to size changes in indentation.

[quietbritishjim]

That's is a much worse user experience. The slack has to be greater for more-nested lines. In other words, you're really just catering to those who have wider tabs.

[citrin_ru]

> But you also have to decide at what point to hard wrap each line based on a max line length

Exact and strictly enforced max line length IMHO unnecessary. Too wide code is hard to read, too narrow too but in between there is a wide range of acceptable values. When possible I treat max length as a recommendation, not hard limit.

When you don’t have a hard limit it’s not a problem if code added by someone who uses visual tab width 2 will go over 78 characters in the editor which tab width set to 4. Equally it’s not a problem when someone using 4 will make a line break sooner than one using 2.

[ecocentrik]

The whole line of thought is just a waste of cycles. /Screams "tabs", sticks fingers in ears and walks away.

[arcbyte]

I dont even understand what youre trying to describe here. What is a wandering right column?

This argument fails by default if its not understandable.

[quietbritishjim]

Like if my tabs are 2 spaces and I save a file like this:

   line1 = wrapped
     + to_here_max
   if something:
     another_line
       = some_val
       + other

Of course this is exaggerated, especially because most lines won't be close to max width let alone exactly at it. But you can set the width of your editor to whatever number of columns that you're hard wrapping to (i.e. what you save in the file) and be sure every line will fit.

Then someone else loads it with tab width set to 6:

   line1 = wrapped
         + to_here_max
   if something:
         another_line
               = some_val
               + other

Now the max column width of a line depends on the syntactic indentation level of it! Any width you choose for your editor will either overflow for some deeply nested lines or waste loads of space on less-nested lines.

Of course it's not a real concern because your editor can probably automatically fix this. But if it's clever enough to do that, then the supposed extra flexibility of tabs is actually possible with spaces anyway.