Elastic Tabs

July 3rd, 2006

Nick Gravgaard has come up with a pretty simple solution to the “tabs vs. spaces” problem. He proposes a system for the elastic interpretation of tabs (via Joel) by text editors. Basically it comes down to treating tabs as indicators of a “new column,” instead of assigning an arbitrary number of spaces to them. The graphic on his page explains it better than I can with words.

A major drawback that he points out is poor readability in older (i.e. all current existing) editors, but maybe it will catch on. I think it’s really cool that you could, for instance, lengthen one line in a block-comment and all the other lines would automatically grow to match that column’s new width. How many times have changed a comment like: 

/* Juicy bits of  */                /* Juicy bits of     */
/* info for our   */   ----TO--->   /* info for our best */
/* client.        */                /* client.           */

Extending the second line meant you had to “up the tab ante,” by manually clicking all the other lines of the block comment and tabbing out its final characters, as well.

I think his system would work well for me in most instances, though I’m slightly concerned that sometimes my code does not fit well into discrete columsn. Maybe it’s just poor style on my part, but for instance I could see myself writing something like this: 

int doodad;   // what a thing;
int flubber;  // also neat
doodad = doSomethingFunnyAndScary(flubber);    // Not too shabby...
flubber = andTheOppositeCouldAlsoRock(doodad); // Lovely!

In other words, sometimes I end up with localized tab-aligned comments that, to remain pertinent to their target, are kept pretty close (just one tab away). Now in Nick’s system, the “column system” for any chunk of code is uniform until a blank line is encountered. So the above would probably end up looking more like this: 

int doodad;                                    // what a thing;
int flubber;                                   // also neat
doodad = doSomethingFunnyAndScary(flubber);    // Not too shabby...
flubber = andTheOppositeCouldAlsoRock(doodad); // Lovely!

It would be easily solved in this case by putting a blank line (which is probably appropriate anyway) between the variable declarations and the code. But I’m not sure yet that all cases would be so easily “fixable.” Still, an excellent experiment and I’ll be curious to see if any major editors incorporate the technique as an option.

This entry was posted to Programming, Technology, Usability, Xcode. Comments are closed. Thanks for reading!

5 Responses to “Elastic Tabs”

  1. Michael Kussmaul Says:
    July 4th, 2006 at 2:40 am

    I’m always wondering, when the 50-years old way of source-code formating finally goes away… My dream-source-code-editor would adding embedded pictures, sticky-notes, etc (much like more modern word processors, like Pages, Word, etc). How often had I to ASCII-draw message-flows into source-code, instead of simply embedding a nice picture, or adding a collapsable sticky-note, instead of spoiling the source-code with 10+ lines of extensive comments…

    It seems all current editors are still focused on 80-line text and cryptic handling of comments (adding // */, etc) – I hope the day will come, when this will finally change :-) Not everyone likes EMACS, VI for coding, I want a nice GUI, which also offers the benefits of a GUI :-)

  2. Michel Fortin Says:
    July 4th, 2006 at 5:04 am

    These elastic tabs are nice, but they\’re going to clash with indentation in some cases. (The first code sample rely on proper indentation which did not work with the live preview, let\’s hope it will work once submitted.) Here is a big regular expressions comming from PHP Markdown for which this particular kind of indentation won\’t work (unless you insert a lot of blank lines):

    $text = preg_replace(\'{
        (                         # $1: Marker
            (?< !\\*\\*) \\*\\* |   #     (not preceded by two chars of
            (?<!__)   __       #      the same marker)
        )						
        (?=\\S)                    # Not followed by whitespace
        (?!\\1)                    #   or two others marker chars.
        (                         # $2: Content
            (?:
                [^*_]+?           # Anthing not em markers.
            |
                                  # Balence any regular emphasis inside.
            ([*_]) (?=\\S) .+? (?<=\\S) \\3    # $3: em char (* or _)
            |
                (?! \\1 ) .        # Allow unbalenced * and _.
            )+?
        )
        (?<=\\S) \\1             # End mark not preceded by whitespace.
    }sx\',
    \'\\2\', $text);

    And even with inserted blank lines it\’s never going to solve something like this either:

    $conversion_table = array(
    \'a\' => array(\'Á \',\'â\',\'á\',\'ä\',\'ã\'),
    \'e\' => array(\'è\',\'ê\',\'é\',\'ë\'    ),
    \'i\' => array(\'ì\',\'î\',\'Á­\',\'ï\'    ),
    \'n\' => array(                \'ñ\'),
    \'o\' => array(\'ò\',\'ô\',\'ó\',\'ö\',\'õ\'),
    \'u\' => array(\'ù\',\'û\',\'ú\',\'ü\'    ),
    \'y\' => array(            \'ÿ\'    ),
    );

    But for both code samples, I suppose a different layout could be used, maybe it would be less pretty but it would still work, while the rest of the code benefits from elastic tabs. But while it wouldn\’t work everywhere, I have to admit I like the idea of elastic tabs. It could be a real time-saver.

  3. Michel Fortin Says:
    July 4th, 2006 at 5:12 am

    Oops! Apparently I shouldn’t have posted a regular expression with <? in it: most of it got swallowed as a tag. And the <pre> tag didn’t pass either, so spacing isn’t right even in the second example. I hate JavaScript live previews which can’t show you what really happens when you submit.

  4. Daniel Jalkut Says:
    July 4th, 2006 at 7:05 am

    Sorry about that Michel. WordPress (or my configuration of it?) has some funky postprocessing that sometimes bites things like this. I face the problem sometimes in posts, too, where I need to carefuly replace < with < to get the desired effect. If you can either get another comment posted here or email me the unadulderated content, I will make sure it looks good in the original comment and then delete these fixup comments :)

  5. geoff.mollyandgeoff.com » Monday Links Says:
    July 14th, 2006 at 9:36 pm

    […] This debate will never be settled.   […]

Comments are Closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.