4 ms·

For me, it's alignment that makes proportional fonts absolutely unusable.

by duaneb 13y ago

kennywinker 13y ago
Tab alignment still works. I work around the rest in my theme by making comments monospaced, which I use occasionally to do ascii art.
jerf 13y ago
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.)
- wiredfool 13y ago
  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).
- ics 13y ago
  What a coincidence! rms from a few days ago... https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00515.html https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00...
  - jerf 13y ago
    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.
Stratoscope 13y ago
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.
- dspillett 13y ago
  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.
- sanityinc 13y ago
  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.
  - kisielk 13y ago
    Almost every diff and code review tool I've used can ignore whitespace changes.

For me, it's alignment that makes proportional fonts absolutely unusable.

by duaneb 13y ago

For me, it's alignment that makes proportional fonts absolutely unusable.

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

jerf 13y ago

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.)

wiredfool 13y ago
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).
ics 13y ago
What a coincidence! rms from a few days ago... https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00515.html https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00...
- jerf 13y ago
  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.

Stratoscope 13y ago

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.

dspillett 13y ago
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.
sanityinc 13y ago
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.
- kisielk 13y ago
  Almost every diff and code review tool I've used can ignore whitespace changes.