Configurable \t width

According to the Telnet specification, when encountering a \t the output is to be taken to the first tab stop. Nowhere does it specify when/where such a tabstop is to be.

Is this a configurable option? (I've searched and failed to come up with something amongst all of the tab-completion topics...) If not, can it be made one with the [GS]etOption configurability to go along with it. (That is assuming it is to be a linear function, although every tabstop being configurable would be very nice as well in which case I am not sure how that would be expressed.)

Some games do use \t, and it would be nice to properly be able to influence how that stuff looks. (Without the trigger-affecting mess that changing the packets to spaces is.)

See:

https://github.com/nickgammon/mushclient/blob/master/doc.cpp

Line 2225 (at present):



Looks like it is fixed at 8.

Okay. I guess I can deal with the situation being as it is. :-)

Somewhere in my head I could have sworn it was configurable, but looking through things again, I may have remembered the tab-completion characters setting in the global preferences.

Also thanks for the relevant line in the source; while I obviously know of the latters existence I can't say I was in any rush to download and grep the thing for \t, 0x09, plain 9 or whatever it may have been written as. (On the assumption it wasn't configurable, which I wasn't really on to begin with. :))

I suppose that also explains why some text editors are annoying as hell. In most "modern" uses, an indent, which is the most common use of a tab, is 5 characters, and when coding, most sane people don't use more than 2, because the deeper the indent, the fewer nested sections you can have, before the code starts wrapping itself, and making it unreadable. Frankly, I don't even know why they thought it made sense in Telnet. :p

I don't think I ever encounter editors where this isn't configurable.


For rapid visual differentiation of nests, most developers I know prefer 3 or 4. 1 or 2 simply isn't enough space difference to easily scan with the eyes. By a more reliable definition of sane, someone sane uses an environment with configurable tab width and just uses actual tabs instead of spaces because we're in the 21st century now and can do modern things with modern software.


What? Your lines are too long, your screen is too small, and you seriously nest conditionals way too much if this is a problem for you.

Agreed with Fiendish. Tabs are by far superior to spaces; it's just that people insist on mixing them and then tend to go 'tabs are so unreasonable!'.

Fiendish argument is pretty much my line of thought in asking about being able to change this. :)

Nowadays I reject tabs in source.

I just change them to spaces. That way I know how it's going to look, in Editor A, Editor B, and when presented on the Web.

I agree with you for display, but not for multi person editing or other in-house stuff where developers are going to be using development tools. I'd much rather have something on the display end that translates tabs into spaces for web viewing than force every developer in a group to be stuck with a particular indent width. Inevitably you end up with someone contributing source who used an editor that gave 4 spaces instead of 3, or 3 instead of 5, which makes things difficult for everyone involved.

(mixed line breaks are a whole other nightmare which should again just be handled by a smart vcs (Perforce handles this automatically, eg) instead of text editors. Did you know that visual c++ 2008/2010 can just refuse to open code files that have mixed line endings until you fix them in a different editor? mindblowing, right? anyway, I digress.)

It's "our way or the highway", right?