Hacker News new | past | comments | ask | show | jobs | submit login

When you press the "next-line" key, it's nice to know where you're going to end up. With a non-monospaced-font, you have to guess or count. With a monospaced font, it is visually obvious.



When I hit "Return", it duplicates the current line's leading whitespace on the next line. That will still work perfectly with a proportional font. When I hit "cursor-down", most text editors that allow proportional fonts know how to put the cursor where it visually belongs.


But that is exactly how my next-line key behaves, my cursor is always exactly where it should be. It's not like your tabs/spaces vary in width from line to line it is just that an uppercase W is wider than a lowercase i.


If you only want to move to the next line if you are at the beginning or the end of the line, I guess it works. For any other navigation, your cursor jumps to a random position. I just tried this, and for any line longer than about 3 characters, "next-line" becomes "random position on the next line". Not useful.

Other problems include lining up similar constructs:

    my $foo = Foo->new(
        bar  => 'baz',
        quux => 42,
    );
With a non-monospaced font, there may not be an integer number of spaces that would allow you to align things.

Using a proportional font for programming seems like using a railgun to put a square peg through a round hole. Sure, you can do it, but why not just get a round peg?


Scintilla-based editors, GTKsourceview-based editors (I just tried with Scite and Gedit) and Emacs all correctly position the cursor when using the arrow keys and proportional fonts.

As for lining up similar constructs, I mostly code in Python, and the PEP 8 style guidelines explicitly forbid that.


I tried it in Emacs. Your definition of correct does not agree with mine.

If you draw a line parallel to the left-hand edge of your monitor down from the character that the cursor is currently over, it should touch the character that "next-line" will move to. That is not what happens when you use a proportional font in Emacs. (If you are on the 10th character of the line, you will move to the 10th character of the next line.)

What happens makes mathematical sense, but Emacs is a visual editor. Programmed text editing is nice, but sometimes you notice a visual property of the source code, and would like to exploit that instead of some lexical property. Visual editing lets you do this, but proportional fonts destroy this ability.

Anyway, sorry to hear about the Python style guidelines. If I did Python, I would ignore that one. (Haskell is whitespace-sensitive and allows you to align similar constructs. So this is just a Python thing.)


> I tried it in Emacs. Your definition of correct does not agree with mine.

Yes it does. In Emacs, with a proportional font, if I'm on the 10th character of a line and press "up", I do not necessarily move to the 10th character of the previous line. I move to the character visually above the current one.

Sorry it doesn't work for you - we must have differing Emacs setups. I'm using Emacs 23 in GUI mode.

Also, I'm a big fan of Haskell in general, but sometimes when I'm coding I think its whitespace is a bit too significant.


Me too. I did "set-buffer-face" to "variable-pitch".




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: