Archives

Code Editors

Why do we still use fixed-width fonts for editing code?

Share

16 comments to Code Editors

  • My mind started in “Obviously, because…” and then stalled. But I was able to come up with some items:

    It’s very helpful for Python since indenting controls blocks and it would be more difficult to interpret (but not impossible) without it.

    It’s useful in embedded work when defining (arrays of) constant strings that need a certain length since I can look at all of them and quickly compare lengths.

    It’s useful for editing in general when I want to do a column-select or column-insert with Slickedit (and I bet emacs has a similar feature since it has every feature somewhere…).

    • I’m now attempting to work for today in a variable width font. Assuming I don’t need any column features, I should be okay. Actually, a quick test shows that Slickedit still allows column-select with variable width fonts and does the right thing. Boy does it look weird:

    • Python’s indented control blocks still look fine, since all space characters are the same width even in a variable width font.

      Emacs does have a column-select and column-insert features (naturally :) ), but 99.9% of the time I only use them to increase or decrease indentation. Do you use them for anything else?

      It might be nice to have a programmer’s font that uses an n-sized or m-sized space character and different kerning rules for special punctuation like the period symbol.

      • The thinness of the space character was what I meant by being more difficult to use variable width for block indenting. It could get easy to accidentally miss a one-space indent error. A m/n sized space would fix that.

        I use the column features a lot when (un)commenting large blocks (I avoid /* */ whenever possible), when defining enumerated lists so I can put a common naming prefix on all of them, when changing indentation, and sometimes when defining a whole bunch of variables of the same type. Slickedit’s column mode actually lets you select a column and then start typing and have what you type be inserted on all rows simultaneously.

        • That sounds similar to emacs’s string-rectangle function (C-x r t). I think that would work and look fine, since in all of those use-cases all of the text to the left of the insertion point is identical on every row. If I understand correctly, anyway. :)

          • I’m also starting to realize there’s a subtle feng shui sort of thing going on when I work on fixed width fonts that puts me in the mindset of everything being orthogonal and byte-oriented. Maybe not as important to programmers on large systems, but I think it helps me get in the mindset for embedded systems more easily…

          • As you move over a brace/parenthesis/bracket, Slickedit momentarily bolds it and it’s partner.

            Now that I’ve enabled variable width fonts, this makes the code wiggle and move as I scroll through it.

            The feature can obviously be disabled, but is on by default.

          • Hmm, yeah, I think for variable-width fonts to work with code, all of the context fonts and whatnot need to be in the same font and style (though you could still do things like momentarily inverse color).

  • I code in Zapf Dingbat and demand everyone else does too.

  • So, one day down and it wasn’t that bad at all… The wiggly-bold text was the only really annoying thing I found, and that could be fixed.

    On the up-side, I’m using a much nicer font now and it’s a bit easier to read. Plus the bold/italics code highlighting really pop out now.

    Your comment about column-select features lining up for how I use them was correct, since they were always bordered on the left by identical text. Even if it wasn’t all spaces, it still lined up.

  • Because you’re using a VT420? :)

  • Multi-line calls get indented confusingly with variable width:

    printf("Some format string: %d %d %d\n",
           x,
           y,
           z);

    The x,y,z are all lined up with each other, but not the printf line.

Leave a Reply