Alignment is the problem here, not the proportional font.

I gave up alignment in my code many years ago, back when I was still using monospaced fonts. I gave it up because I was really tired of fiddling with spaces when I changed a name in code like this:

  myType someFunctionName(someType      someVariable,
                          someOtherType someOtherVariable,
                          int           foo) {
      ...
  }

So I started doing this instead:

  myType someFunctionName(
      someType someVariable,
      someOtherType someOtherVariable,
      int foo
  ) {
      ...
  }

I found that I just didn't care that "someVariable" and "someOtherVariable" weren't lined up one above the other. In fact, I actually liked the fact that the variable names and types were closer together, so my eyes didn't have to keep scanning across a sea of whitespace to match things up. And I really liked not having to add and remove spaces every time I changed a name.

As a bonus, the overall width of my code was often much less, as in this example.

Later I discovered that using this style, my code looked the same in a proportional font as it did in a monospaced font. So I switched to a proportional font and never looked back. But the code is still just as readable in a monospaced font.

I still use space based alignment a fair bit, though it can be faf. What would be really nice is for a code editor to support some sort of elastic tab-stop so I can tell it that some things should stay aligned and have it do any extra work needed. I'm not sure how that could be made low-/zero-effort easy from a UI PoV though, but it would work just as well with proportional fonts too.

Plus, as variables get added and renamed, the resulting realignment of tokens modifies lines unrelated to those changes, leading to messy diffs which degrade the effectiveness of most version control tools.

Almost every diff and code review tool I've used can ignore whitespace changes.

I clocked substantial time in Frontier back in the day, where alignment was fundamentally handled by the outliner core, so the text could just be wrapped as in an outliner. It works fine. I don't know what syntax highlighting would look like since I haven't seen it.

It does seem like the programming environment and language must be designed for it to work nicely, though. I've tried proportional fonts in several environments since then and it's always sucked for one reason or another.

Possibly Go is structured enough for proportional fonts to cleanly work though. Haven't tried it yet; I use emacs and last time I tried proportional fonts in that it was a joke. (And that was just straight-up English, no programming at all.)

What a coincidence! rms from a few days ago... https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00...

Ha! Cool.

I suppose I should in fairness observe this was actually a long time ago. Since then emacs has switched to XFT; I haven't tried it since then, because well, as I mentioned most languages don't work very well with it either. But perhaps I will try it in a Go buffer here.

(A few minutes later.) Hey, this isn't so bad. I'm not sure everybody would appreciate me sticking with it since it makes it hard to tell when you've got a "long line", but it's certainly radically better than I remember from the last time I tried this.

For those who may want to play at home, I use the Droid series of fonts for my programming and I just eval-region'ed this:

    (custom-set-faces
     '(default ((t (:stipple nil :background "#ffffff"
       :foreground "#141312" :inverse-video nil :box nil 
       :strike-through nil :overline nil :underline nil
       :slant normal :weight normal :height 105
       :width normal :family "Droid Sans")))))

YMMV may vary, of course. Especially if you're not using a white background. :)

Go's attempt to auto-align struct name and types isn't working so well, though. (Fortunately, gofmt takes care of it so I still can't be wrong.)

Further follow-up: You don't realize how much you're subconsciously using the "shape" of the code to guide you until you change it and suddenly feel lost, like I'm in a fresh code base I've never seen before, despite the fact I'm actually in something I've more-or-less written from scratch over the past six weeks, which is just about the maximum level of familiarity you can have with a piece of code.

Frontier? Me too. I even brought one of the bitmap fonts from os9 to osx because it just worked better for me. (New York 9, I think).

Tab alignment still works. I work around the rest in my theme by making comments monospaced, which I use occasionally to do ascii art.