Instead of a downvote, how about a real explanation of why exactly monospaced fonts are actually required.
This bit of programmer dogma is totally unfounded. There is nothing more to it than tradition.
This bit of programmer dogma is totally unfounded. There is nothing more to it than tradition.
Other problems include lining up similar constructs:
my $foo = Foo->new(
bar => 'baz',
quux => 42,
);
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?
As for lining up similar constructs, I mostly code in Python, and the PEP 8 style guidelines explicitly forbid that.
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.)
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.
The situation is different with code. Every character that you type, unless it's within a comment, is very important. It's even quite possible that accidentally putting two spaces after a period might have some semantic effect, and it's certainly possible that having two periods instead of one will have some semantic effect. The programmer absolutely must be able to easily read code on a character-by-character basis, and thus he wants a typeface that treats each letter absolutely equally. It's only slightly distracting if your W is wider than your L, disrupting the natural grid of your text. But in a language where punctuation is just as important as the words themselves, you might just as well be troubled if your periods or commas have a tendency to disappear into the flow of letters.
Not to mention that there is nearly no block text font that has as much of an interest in differentiating I/l/1 and 0/O as programming/monospace fonts do.
Some modern monospaced fonts are rather nice to look at, Consolas for example, and the ability to distinguish between 0O1l easily is an advantage for some fonts without having weird letter spacings.
When I started my non-monospaced experiment 2 years ago, I, thought I might have trouble differentiating between 0O1Il, etc. but that has never been a problem in practice.
(Python's PEP8 is meant to take care of abuses, like lining up all the equal signs in a series of assignments or keyword arguments -- you wouldn't think of those as columns of data in a table, so there's no point in formatting the code that way.)
Also, monospace makes punctuation more prominent. Bjarne Stroustrup's C++ reference book uses a mixed font in its code examples, with monospace punctuation characters and proportional-font identifiers. It's weird but effective. I suppose if your code doesn't do exciting things with punctuation characters, and doesn't embed tables of data, then a proportional font would be just fine.