Comments on: Elastic Tabs

By: geoff.mollyandgeoff.com » Monday Links

geoff.mollyandgeoff.com » Monday Links — Sat, 15 Jul 2006 04:36:49 +0000

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

By: Daniel Jalkut

Daniel Jalkut — Tue, 04 Jul 2006 14:05:50 +0000

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 :)

By: Michel Fortin

Michel Fortin — Tue, 04 Jul 2006 12:12:01 +0000

Oops! Apparently I shouldn’t have posted a regular expression with in it: most of it got swallowed as a tag. And the

 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.



By: Michel Fortin
Michel Fortin — Tue, 04 Jul 2006 12:04:33 +0000
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.


By: Michael Kussmaul
Michael Kussmaul — Tue, 04 Jul 2006 09:40:16 +0000
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 :-)