• 6×10 X11 font. That’s the font I prefer when I am using a screen of around 100 DPI (such as my 24″ 1920×1200 screens). This font, despite being very old, has still, in my eyes, this perfect balance between legibility and compactness; something that even other fonts in that series (of X11 fonts) do not quite have. It’s installed by default on *nix boxes, but for Windows, you can get them here.

  

• Proggy Clean. That’s my second bestest font that I use on very tiny tiny screens around 100 DPI, but it does not always play well with Emacs (some weird DPI detection setting issue). The complete font set can be found at proggy_fonts.

  

• Terminus. That’s the one I use for my shells. A bit larger than 6×10, but still rather harmonious in its proportions. It is not installed by default on Linux, but it’s somewhere in the Debian or Ubuntu as packages console-terminus and xfonts-terminus*. For Windows user, it is available here.

  

• Envy R. This font is a vector font and scales well with different screen densities. It does not render optimally under 12pt size, but is a good, smooth, legible font for screens with a very high DPI (say, much above 120). I use it to write normal text (such as LaTeX in Emacs). It can be downloaded from here.

  

• Inconsolata is an open-source/free reimplementation of the non-free font Consolas that can be downloaded from here. I like this font when I’m really tired (or on very high DPI screens) as it renders well in large pt settings (12 and above) and is very legible.

  

There are of course LOTS of other possible console fonts (some very nice, some being incredibly sucky). A ton of other fonts can be found on the Monospace/Fixed Width Programmer’s Fonts page by Trevor Lowing.

And you, what are your favorite coding fonts and why?

In my case, I have a series of macros that control conditional compilation (such as described in a previous post). Suppose I have set of macros BEGIN_UNIT_TEST_ONLY, END_UNIT_TEST_ONLY and UNIT_TEST_ONLY that start a unit-test specific block of code, ends it, and enables only a single statement, respectively.

These are UGLY_MACROs and I want them to poke conspicuously out of the source code. So, How do I tell Emacs to display them in a special way, using bright ugly colors?

The first thing to do if you don’t want to reuse an existing face customization (such as font-lock-comment-face, for example) is to create one. Let’s start with a new face descriptor initialized with a default color. In my case, I wanted it to inherit all properties of normal text except for its color. You add:

(make-face 'font-lock-special-macro-face)
(set-face-foreground 'font-lock-special-macro-face "pink")

This creates a new face named font-lock-special-macro-face set to pink. Or whatever color you’d like. I used magenta finally, because although it is ugly, it’s still better than pink in my color scheme.

We proceed to add regular expressions to the list of keywords and associate each regexp with a face.

(defun add-custom-keyw()
  "adds a few special keywords for c and c++ modes"
  ;
  (font-lock-add-keywords nil
   '(
     ("\\<\\(UNIT_TEST_ONLY\\)" . 'font-lock-special-macro-face )
     ("\\<\\(BEGIN_UNIT_TEST_ONLY\\)" . 'font-lock-special-macro-face )
     ("\\<\\(END_UNIT_TEST_ONLY\\)" . 'font-lock-special-macro-face)

     ; more of those would go here
     )
   )
 )

Which we hook to the initialization of C and C++ (minor) modes:

(add-hook 'c++-mode-hook 'add-custom-keyw)
(add-hook 'c-mode-hook 'add-custom-keyw)

and voilà! we’re done. When the c- and c++-mode initialize, they will run add-custom-keyw, and they will activate with the desired face. You can enjoy the result:

*
* *

Thanks to the people of #emacs on Freenode.org for hinting be to the right solution. Emacs programming isn’t the easiest of all. Fortunately, there’s google and the Emacs wiki.

Let’s pretend we have a piece of code (one that you have seen before already):

This is already pretty legible—at least according to my tastes. What could we do to make it even more legible?

Enhanced Scope Visibility. With an editor like Emacs, you already have parentheses/brackets/braces/chevrons matching/highlighting in most “major modes” like C, C++, Java, XML, etc. If it cues you visually on the matching element by highlighting both, it doesn’t show you how scopes are nested, unless you walk between nested elements using … well, some short cut like C-M-u and C-M-d. I’d much rather have a scope highlighter that could work like this:

Which would work, if the shades allowed are subtle enough, in many color schemes:

Adaptive Reduction of Visibility. If you edit complex code, the editor’s screen eventually fills up with text. The more complex the things you are editing, the more the screen looks cluttered (in my opinion) and you have to make an extra effort to concentrate on the precise object you are editing. The very counter-intuitive thing to do is, rather that put more stuff on the screen, is to make sure you see only the stuff you need to see, and somewhat reduce the number of things one can view. One possible solution is to use a spotlight of sorts:

which would be controllable or disabled by the user any time it’s in the way; for example, binding meta+wheel to adjust the radius; another solution could be to apply some kind of hyperbolic deformation of the lines:

(OK, clearly, I’m not a GIMP ninja just yet). But imagine that it is smoothly warped with texture filtering and everything you want so that text remains legible until it gets really small. Imagine also that the degree of curvature depends on the scope surrounding your cursor; a small inner scope would cause more warping to the rest of the text, a larger scope would cause less or even no warping, depending on how large it would be.

Maybe this last one is too much? That’d be a neat alternative to the [±] boxes we have to collapse/expand functions.

*
* *

I think, however, that the only really useful one, that needs the less getting used to, is the “enhanced scope visibility” mode. However, to work properly, it has to be subtle; the effect cannot be achieved without melting your eyes on a 16 color display. You must have many shades of the background color available, and maybe finer shades than in the example. In the example, I show increments. Maybe the effect would have been better with smaller increments?