It slightly alters the monospacing which would drive me batty when coding, but cool idea. Especially for displaying code like in a blog post or other non-interactive use.
Well, depending on your audience I think it would be a step backward for static display of code since in some cases it isn't clear what to actually type. Fine for experienced audiences but really frustrating for anyone learning.
For example, the 'x' in the hex value. Is it a regular 'x' or another character? How about those fat arrows? How are those typed?
If you don't use one of those fonts that support ligatures, you'll see the plain ascii characters. You shouldn't use these fonts if you don't know what kinds of ligatures it supports or how it converts plain ascii characters into a higher form.
In my experience using Fira Code with VS, VS Code, and Konsole, the monospacing isn't a problem. The ligatures are designed so that they fill up the same width as the original characters.
My opinion might be biased by a heavy math background, but I like that e.g. "less than or equal" now looks the same as the way I write it on paper, and I don't find myself spending any time thinking about what that symbol means.
I'll concede that it totally messes up command line help text in the console, though. You get lots of stuff like --parameter=<value> turned into —parameter≤value> but it hasn't annoyed me enough to switch back yet.
In the GIF, you can see the other characters earlier in the ligature shifting around when a character is added or removed to complete or undo the ligature. That would just bother me.
Ah, that's fair. It is a little bit of visual noise, maybe roughly equivalent to the blinking of matching parens or braces as you move your cursor around.
I think the slight improvement in visual clarity when reading the ligatures makes up for the slight noise when writing them, but it's definitely a personal preference.
I happen to like them, but the only one I'd put forth as a definite improvement is that JS/PHP's triple-equal === operator gets turned into three horizontal lines that take up more vertical space than the double-equal does. That can be the cause of subtle bugs, so I think making that distinction more obvious is a win.
Personally, I'd probably find it easier to visually mix up the two-line and three-line versions than to mix up the two-char and three-char versions when skimming code - but to each their own.
It transforms them from individual characters being put together to approximate symbols into the actual symbols. The act of joining together particular character combinations into more aesthetically pleasing forms is common and very old practice.
It looks odd only because we're accustomed to seeing the individual characters due to display limitations inherited from typewriters and TTY machines.
The www is a bit artsy for my tastes as well, at least in a programming sense, but making a ligature of www isn't a terrible thing, IMO. It already almost creates its own ligature, especially when used with a serif font.
Heck, a lot of people I know will make a verbal ligature of www - something like 'dub dub dub'.
www was unnerving to me (and a couple of my team members) too.
In a way I am interested in psychological basis for my innate rejection of this. Conceptually, I comprehend why it is made into it's own ligature, like !=, it is a unit of information these days.
Well, for starters it's an abbreviation, whereas -> or != is an approximation of a symbol, so that makes it different from the rest. Also, you're on a website that has no www in any part of its website, so it's not nearly as ubiquitous.
If anything I think it makes more sense to have :// as a ligature.
> The act of joining together particular character combinations into more aesthetically pleasing forms is common and very old practice.
Yep, the ampersand symbol "&" originated as a ligature for et, Latin for "and". You can see this more obviously in italic families and some fonts expose a more fancier variant as well. Example: http://i.imgur.com/Rsmmql9.jpg.
Use them for a bit before judging it, don't forget that you've trained yourself to read some character combinations as meaningful.
After using Fira Code for a while, I can say code looks weird without it. Especially plain === and => look really jarring now. The ligatures also help me spot typos!
Regardless of the ligatures, one of the cooler things about Monoid is how it tries to fix kerning problems inherent to monospace fonts:
I'd like to use it, but they turn custom operators such as "|>|" into an illegible jumble of characters (in this case, "▷|"). If I'd wanted my operator to be "▷|", I'd have defined it that way.
Now, if they can come up with a way to selectively turn the ligatures off and on, I'll give it another go. Until then, I'm perfectly happy to see the occasional "<=" or something.
Also, that "www" ligature is the stuff of nightmares. Never, ever, with I use that on my computer.
I assume potential sarcasm would be related to the difficulty differentiating between similar symbols, based on length, with different lexicographic meanings.
For example, dash vs endash vs emdash, etc:
‒ – — ―
If those symbols were used in a programming language and had different meanings, differentiating quickly could be much more difficult than seeing the difference between -, --, ---, and so on at a glance.
But the point of the new triple-equals ligatures is that they're no longer only differentiated by length; they have three bars instead of two, as well.
> the difficulty differentiating between similar symbols, based on length, with different lexicographic meanings.
The very thing amk_ is praising is that this issue is fixed in both Fira and Monoid by the triple-equal being not just longer but represented using 3 horizontal bars rather than just 2.
I noticed that immediately, too; I just assumed the author changed the source before taking screenshots and forgot to update it on site code. If a font was doing that, it would be criminal.
Sorry, the missing C is just me being sloppy. The underscores are a C#7ism where you they are ignored and people can use them to separate LONG hex literals.
I really like the ligatures in Iosevka ligatures when working with Javascript, especially with `=>` (which it turns into a fat arrow). It's not really that significant, but it's a nicety that enjoy.
The www was a little weird to look at for me too, but it's the combinations of multiple "-" and "=" that pushed this over into "nope" territory for me.
It's cool that some folks find it better, but it's just not for me
I like switching fonts every couple of years just to keep it fresh.
My font right now is Iosevka: https://be5invis.github.io/Iosevka/ A font generated from its source code. You can build your own variant. It has ligatures as well.
I like that it’s not as wide as many other monospace fonts.
Seconded. I swore by Inconsolata for the better part of a decade but within days of installing Iosevka I had it set up in every editor or terminal on all of my computers. And it supports programming ligatures!
like Dawn replied I'm shocked that someone able to profit $8730 in a few weeks on the
> internet . you can try this out>>>>>>>>>>>http://ow.ly/iBXm30dNtIZ
I've rifled through many a programming font, bought Pragmata Pro at one point (as you can see I also like taller fonts), tried many others over the years (Monoid was my previous favorite ligatured font). Iosevka is my current favorite. My customization args are part of my dotfiles repo so I can install it exactly how I like on any new system without effort.
My problem with Iosevka (and Input and others like them) is that the [x-height][0] is too large, ie the bottom-half parts are too tall compared to the top-half and uppercase letters. Especially in less-wide weights, it feels muddy and hard to distinguish.
I love Iosevka Term! My only issue with it is that there seems to be a problem in Emacs 25 that makes the screen flicker once in a while when I use it. For Emacs, I like to use Fantasque Sans Mono, another amazing font.
For some people this might be great but for me this is a total sensorial overload, I tried to use some of these fonts in the past and I just loose track of the code.
Did anyone experience the same in the begging and grew to actually like these fonts or was it always a "love at first sight" experience for you that use them?
There was definitely a lot of "whoa!" and distraction in the beginning, especially while typing and watching things transform.
Later I loaded up some JS code I was working in earlier but without ligatures as the terminal I was using didn't support them. It definitely felt oddly verbose, especially the arrow functions.
I can still go either way, but it's mostly lack of ligature support that keeps from adopting it wholesale. Changing one way or another is a tad disruptive.
I personally love hasklig. Iterm2 has it on the Mac, but I'm sol on Ubuntu.
Is there any good terminal app that supports ligatures? I tried konsole, but the font looked like it wasn't getting any anti-aliasing and was harder to read as a result.
I love terminator, but it doesn't support ligatures.
I am a huge, huge fan of the free font “Input”[1]. Just love how customizable it is, so much so, that I’ve replaced Pragmata Pro with Input on Sublime.
I love Firacode and use it in Android Studio/IntelliJ but it has this bug[0] where "=" is invisible in Gnome terminal. So, I had to switch to Fira Mono[1], the parent of Fira Code, from Mozilla. Fira Mono doesn't have cool ligatures but it's a good font and works pretty well.
Apparently I'm one of the two users of proportionality spaced fonts for coding. I've used this now for five years and I don't understand why developers still see this need to code as if monospaced terminals is all that's available. Especially on large screens with high dpi it reads much faster. It also makes it less awkward to use editor unicode substitution for display purposes.
If like me you really like aligning your code proportional fonts are not exactly pleasant to use. I sometimes go out of my way (within reason) to have variables with the same number of letters so that I can align them nicely. A bane of my existence is that "width" and "height" don't have the same number of letters.
An example from some lua code I'm working on at the moment:
local hi = buffer:bitfield(4, 4)
local lo = buffer:bitfield(12, 4)
return bit32.bor(bit32.lshift(hi, 4), lo)
I find that aligning things not only looks better but also makes the differences more obvious. Same code with a proportional font:
local hi = buffer:bitfield(4, 4)
local lo = buffer:bitfield(12, 4)
return bit32.bor(bit32.lshift(hi, 4), lo)
It's not a deal breaker (and the offset is small in this case) but I much prefer the monospaced version. Obviously it might also be "Stockholm syndrome" after decades of coding with a monospaced font, I can't say I've really given proportional fonts their chance.
Also many proportional fonts make it hard to distinguish between Il1 or O0, but I guess you could design a proportional font that doesn't have this issue. What font do you use yourself?
The Il1 problem is primarily a problem with sans-serif fonts. In my work SmallTalk text is set in Arial in the default image, but I've set up my development image to use Cambria instead which is really quite nice.
The inability to do vertical alignment outside of the left edge of the line is a bit annoying, but honestly I don't miss it that much. If you have enough code that you really, really need to do that, I find it's a code smell indicating that something likely needs to be broken into smaller pieces anyways.
I'm normally using Optima when working on Retina displays (because of serif typeface). Screenshot [1] of some old project for solving Project Euler problems (no solutions can be found in the screenshot).
After programming in SmallTalk for a while, I'm starting to come round to a similar point of view. I haven't quite made the leap in my day-to-day work yet, but I really am considering it.
Another thing I'm considering to adopt from ST is dropping syntax highlighting. If research on highlighting for natural language can be transferred to code (I'm not entirely sure, but I suspect it might), highlighting might actually be harmful to comprehension. The only thing I'd keep is a slightly lighter colour for comments, as these don't have quite the same status as code. Ideally, I think I'd like to have them deemphasised by moving them off to the margin or something like that, but that requires rather more work than rendering them a lighter colour than the rest of the code.
> If research on highlighting for natural language can be transferred to code (I'm not entirely sure, but I suspect it might), highlighting might actually be harmful to comprehension.
Interesting. Could you share some of that research and its conclusions?
I don't remember whose research it is (it's a bit removed from my field of expertise =), but the gist of it is that they tried to highlight different parts of speech in running text in different colours, and showed that it actually decreased reading speed and comprehension.
Of course, there are several possible error sources (unfamiliarity with the colouring scheme for example), and whether this can be transferred to reading code is an open question. But I still think it's important to keep the existence of this kind of research in mind when discussing this kind of question (and also the similar question of mouse-driven interfaces vs. keyboard shortcuts), as it easily devolves into strongly held opinions and arguments along the lines of "it stands to reason that $opinion-held-is-true"
I've always considered those kinds of studies suspect. When I'm reading, human-language text, I spend most of the time going forward. Maybe I'll skip to an earlier part of the sentence if it turns out to be a garden-path parsing, or to a previous sentence to re-acquaint myself with context. Those are exceptional cases.
In code, I'm frequently tracing back and forth through a block, looking for specific information in different lines. I think that the coloration helps to provide "landmarks" for non-linear traversal of the code. I'd consider color-free code to be more similar to un-punctuated text, than I would consider colored text to be to colored code.
Reading code isn't the same as normal book or news reading. You don't need to actually read the whole code. Most of the time we looking for a specific variable or function call. Syntax highlighting allows you to filter out everything that's the wrong color to find what you're looking for faster.
I've tried to look at code without highlighting and I can't read it because the color gives me additional context (metadata?) about the code.
I'm profoundly more productive when syntax highlighting is enabled. It's easier for my brain to focus on the details it needs at any given point, versus when it's all the same color
> Ideally, I think I'd like to have [comments] deemphasised by moving them off to the margin or something like that
This is one reason I'm a fan of Douglas Crockford's slightly unorthodox style of always beginning comments in column 0, rather than indenting them along with the code. This helps, to a small extent, in differentiating comments from code. Example: https://github.com/douglascrockford/JSLint/blob/master/jslin...
Ideally, I'd prefer to float them to the right margin (suggesting the Lisp style of line comments starting at column 78 or thereabouts, I guess), but this is an acceptable compromise. At first blush it seems to break the flow of the code a bit too much, but I'd probably get used to it reasonably quickly, especially in conjunction with grey comments and black text.
I'm sympatheic to Smalltalk's approach to highlighting, but as long as we're all editing text files that contain multiple classes / functions / methods / etc... colorizing a few tokens (like class/func/let) is still valuable.
Personally I use input[0] which is easy to customize before download. If you aren't using a terminal-based editor, I really don't see the point in monospaced fonts either. I've never had an issue distinguishing differences because of the font style.
It could be a function of the kind of programming you engage in.
When I write code that reads more like long-prose, then I do prefer proportionally-spaced fonts myself. This is generally characterized as code with a low density of variables and constants, and lots of control and data structure manipulation. However, when I write code with lots of objects, I tend to prefer monospaced fonts. This is because my personal aesthetic style is to line up groups of related entities and logic; an IDE that gives a modern example of doing this is Eclipse [1].
For IDEs I have to use for a specific project that don't support such formatting, Emacs makes this easy to re-flow so adding a new variable, shortening or lengthening an existing one is still quick. The impact upon version control is still annoying, though; AST-sensitive merge/diff/version-control can't arrive soon enough for me. Fortunately, my code is not regularly inflicted upon others within a team; when I do have to work within a team, I put up with not carrying out my personal preference and use the code formatter that comes closest to the team's formatting standards before checking in.
I do this because it helps me read my own source code quicker. Blocks of entities and logic related by domain and not intrinsically related through the language itself happen to be easier for me to read when I line up like this.
This all goes back to a phase I went through a long time ago when I tried to figure out how to adopt literate programming in all my own work, within the context of an integrated single-source publishing, version control, testing, training, and problem management environment. In my mind's eye, I imagined all the media and activities surrounding a software product related back to the code in some manner, with the code displayable in different contexts based upon the AST and domain-specific hints, and when I made a change in either, I could see and manage the change in the network of related nodes. So if I change how a GUI behaved, then the parts of the User Guide that reference the old GUI, list of users who logged problems documenting confusion about that part of the GUI, etc. would all be automatically flagged. The User Guide would automatically get updated graphics content available from the GUI testing as soon as the testing data was built, the training material as well, and the users would get a note from the support team when the next version was released, detailing the change. I eventually decided that mountain was one I wasn't going to grind down myself anytime soon, so my code formatting is one of the many small ways I preserve that ideal.
Thanks for this interesting write-up on AST-based editors. Smalltalk has some of these ideas, and you might want to have a look at TexMacs (even though the project is abandoned). Like you, I feel that linear text-based editors are severely holding us back in communicating our intentions and inventions. I've had very similar ideas myself and even worked shortly on a Lisp which recursively forms an editor for itself (using a meta-object protocol).
I also prefer proportional fonts, but some people's "ASCII artsy" programming styles, along with editors themselves, make it hard to use readable fonts in practice.
What I would like is a language-aware editor that can visually align assignments, parameters, etc. without touching the actual whitespace characters. You get 1 tab for indentation (if the language allows tabs) and 1 space for alignment, and the editor takes care of the rest. The raw text would still be readable enough and use fewer bytes for people who prefer to code in a monospace terminal over SSH over an acoustic coupler from a phone booth in rural Texas.
It isn't quite what you asked for -- doing this automatically would be really neat -- but the best solution I've seen is called Elastic Tabstops. http://nickgravgaard.com/elastic-tabstops/
I really, really wish this was available in the editor I fight with every day.
Every time I've tried using a proportional font, my mind doesn't want to see it as code. I can force it, but that gets uncomfortable, so I switch back after a short time. Even if I take the time to adapt, that means switching fonts in all my dev environments (between home and work, 7 OSes, 1-4 editors used in each). And a lot of my hobby code is data format conversion, emulation, etc, so I'd need to find a nice way to format the data tables.
There's a good-sized category of things that have a bit of an adoption cost that I'm assured is worthwhile, but that I don't see a really solid reason to commit to. Proportional fonts is one of those (for me).
> I frankly can't understand how tiny font people can function. It gives me a headache to even consider programming at anything less than 14 to 16pt and I am usually around 20pt.
What? I can't understand how such large font people can function. I mean, how large (or dense) are your screens? Is that a Macbook thing?
I'm at... something small. Hard to tell exactly, because on my laptop screen, all following fonts look pretty much the same size, while having different configured values:
- IntelliJ - Monospaced, size 12
- Emacs - (:family "Hack" :foundry "unknown" :slant normal :weight normal :height 76 :width normal)
So 8 / 12pt (which one is pt?) and/or 76 somethings. People at work say I'm crazy working with such small text, but frankly, anything larger for me feels like wasting tons of vertical space, which is of short supply given the (IMO completely idiotic) market standardization on 16:9 and 16:10 displays.
What are you going to do when you get older and your eyes go through "the change"? You can keep your font sizes and wear readers, but then don't you have to move your head a lot to view the entire magnified image?
Any presbyopic developers care to chime in on what the experience is like? I'm 40, so mine could cross over any time now.
I hate 16:9 too. Please give me back the bottom of my screen that you chopped off.
You could try rotating your screen to get 9:16, although I find that it tends to be a bit narrow if you want to split vertically and have two pieces of code side by side.
With 16:10 screens however I think it work rather well, I currently use three 1920x1200 monitors and two of them are vertical, it looks like this: https://svkt.org/~simias/emacs-vertical.png
I spent some years with dual 24" 10:16 screens. It was a convenient coding and documentation reading environment. If the workstation had supported a third screen, I would've requested one to run horizontally, for the rare times I had to view video, or something.
I'm 50 and have been wearing glasses for about 6 years now.
Your neurology adjusts pretty quickly. The first few days, your field of view feels limited. After that it feels normal. It was a delight to adjust my font sizes down on all my devices, back to what I would have used at 30 years old.
This is my solution at work; I love it. The only caveat is that some font smoothing doesn't work as well on rotated monitors, since the pixels are no longer arranged as expected. Of course, with 4k monitors, it's a non issue (not that I can even realistically drive 2x 4k monitors on my MBP.
Given differences in monitor pixel densities, OS zoom levels, and distance from eyes to monitor, comparing any point/em/etc measure is practically worthless.
For example, I can use a 12pt font on my macbook pro's screen, but have to go up to 16pt on my 4k display at home, and down to 9 or 10pt on the 1920x1024 screens in the office. It's a pain, but... <shrug>
Instead, if you really want to compare font sizes, compare either the height relative to the window, or actual size on a ruler held at arms length while at normal viewing distance. That way you can measure the arc-height of the font - something that translates much better with such a wide variance in displays.
My fonts, corrected for device, all end up being around 1/8" ( tall (for capital letters) on a stick held at arms length.
I don't have a ruler handy, so here are two random screenshots I just made, showing terminal and Emacs font sizes I use, relative to my 1920x1080 laptop screen:
Sized to fill my screen, it's about the same font size as my own. Maybe one point size (probably less than 1/32") smaller. The only major difference is that my fonts are smoothed by the higher resolution.
> Given differences in monitor pixel densities, OS zoom levels, and distance from eyes to monitor, comparing any point/em/etc measure is practically worthless.
That’s... false.
With correct DPI settings – determined by measuring – the same font size equals exactly the same physical size.
I have a 1080p 15" screen. I've configured my browser with a minimum font size of 18px as smaller text is hard enough to read, especially in the web pages suffering from the war on contrast. Because I sync my configs, also use them on my 21" 1080p displays on my desktop, but I could probably go smaller there.
That said, I turned off the OS scaling on Windows because apps that didn't support it got scaled by image scaling which resulted in unpleasant blurry messes. As for Linux, I don't think XFCE supports it at all.
On my work rMBP I also use 16px min, even with the OS scaling turned on.
When I was a teenager I used to use 10px fonts, but I tend to use displays at more ergonomic distances these days.
Ligatures are great, but I just love the cursive italics used by Operator Mono. Haven't justified the price to myself yet, but am considering it since I haven't been able to find any other fonts that do cursive italics.
I tried it and instantly switched all of my editors and terminals over - it's clear, legible at different sizes, and the monospace script "italics" are great for variable names, comments etc.
For those of us who use programmable keyboards, it's not a problem at all.
For everyone else, perhaps it should be seen as an editor problem? There's no reason vim can't see that you type != or =/= and replace it on the fly with ≠.
Yeah. The thing that blows my mind is that the guy who runs Input Club (they make/design keyboards with open-source firmwares) sent the USB consortium an email a year or so ago asking if there were any plans to update the USB HID spec for unicode, and the response indicated that he was the first person to ask! Really?!? Unicode was out for a few years before USB even existed, and nobody'd even thought about it before? You'd think at least the word processor industry (which wasn't nearly as homogenous back then) would've jumped on it.
I figured I'd leave this here: I rebuild Iosevka with the Haskell ligature mode on default. I use this for a lot of things (although recently it's gotten no use as I've been working in Emacs).
Since it's a bit of a process to rebuild Iosevka, I just bundled the artifacts: https://goo.gl/gsFm8P
(Please excuse the redirection, this got a LOT of downloads and I have a big azure credit so I hosted it there and youw ould not believe what a pain it is to host simple linkable files on Azure).
This replaces -> and whatnot with unicode equivalents, right?
There are a LOT of problems with that. First and foremost you really do want double character width for these symbols in the iosevka format. Stuff like → is microscopic.
it also seems to adjust the spacing, I have used it with FiraCode and it seems to work correctly. Note my main font is DejaVu Sans, with this I just use the Fira Code symbols for the "ligatures"
The edges of the WWW symbol need to align with the old symbol if they are doing it right.
The && also breaks out of alignment. Alignment is the whole reason I am using mono-spaced fonts.
My history:
IBM VGA (strange j, h, k, etc.),
Courier,
Bitstream Vera Sans,
Lucida Sans Italics (only proportional font, but it looked great at the time),
Consolas,
Kids Play.
Really looking forward to having this capability in Sublime Text. I really love Fira Code. It looks great in Emacs for Clojure development and is right at home with my powerline-esque ZSH theme.
Oh, I didn't even know ligatures is a thing. Learned something.
When coding in Haskell, I used to use the vim-haskellConcealPlus [1] plugin for vim to swap chars being display into nicer unicode chars for various operations.
I'm no longer using it now because it wasn't monospaced and moving around lines was jarring.
If only there's a way to combine the benefits of the two. Monospaced font with ligatures seems to only work for operators that take the same amount of space as their ligature counterpart.
244 comments
[ 3.3 ms ] story [ 221 ms ] threadFor example, the 'x' in the hex value. Is it a regular 'x' or another character? How about those fat arrows? How are those typed?
My opinion might be biased by a heavy math background, but I like that e.g. "less than or equal" now looks the same as the way I write it on paper, and I don't find myself spending any time thinking about what that symbol means.
I'll concede that it totally messes up command line help text in the console, though. You get lots of stuff like --parameter=<value> turned into —parameter≤value> but it hasn't annoyed me enough to switch back yet.
I think the slight improvement in visual clarity when reading the ligatures makes up for the slight noise when writing them, but it's definitely a personal preference.
It looks odd only because we're accustomed to seeing the individual characters due to display limitations inherited from typewriters and TTY machines.
Heck, a lot of people I know will make a verbal ligature of www - something like 'dub dub dub'.
In a way I am interested in psychological basis for my innate rejection of this. Conceptually, I comprehend why it is made into it's own ligature, like !=, it is a unit of information these days.
If anything I think it makes more sense to have :// as a ligature.
Yep, the ampersand symbol "&" originated as a ligature for et, Latin for "and". You can see this more obviously in italic families and some fonts expose a more fancier variant as well. Example: http://i.imgur.com/Rsmmql9.jpg.
After using Fira Code for a while, I can say code looks weird without it. Especially plain === and => look really jarring now. The ligatures also help me spot typos!
Regardless of the ligatures, one of the cooler things about Monoid is how it tries to fix kerning problems inherent to monospace fonts:
https://medium.com/larsenwork-andreas-larsen/class-based-con...
https://github.com/larsenwork/monoid/issues/56
Now, if they can come up with a way to selectively turn the ligatures off and on, I'll give it another go. Until then, I'm perfectly happy to see the occasional "<=" or something.
Also, that "www" ligature is the stuff of nightmares. Never, ever, with I use that on my computer.
For example, dash vs endash vs emdash, etc: ‒ – — ―
If those symbols were used in a programming language and had different meanings, differentiating quickly could be much more difficult than seeing the difference between -, --, ---, and so on at a glance.
The very thing amk_ is praising is that this issue is fixed in both Fira and Monoid by the triple-equal being not just longer but represented using 3 horizontal bars rather than just 2.
http://imgur.com/a/LQVV2
IMO it's comparable to a WYSIWYG equation editor vs looking at raw LaTeX - conceptual errors pop more.
It's cool that some folks find it better, but it's just not for me
But of the three screen shots offered, it looked like the worst and the www looked really bad.
My font right now is Iosevka: https://be5invis.github.io/Iosevka/ A font generated from its source code. You can build your own variant. It has ligatures as well.
I like that it’s not as wide as many other monospace fonts.
I do like it a lot, but find myself going back and forth between it, Fira Code, Pragmata Pro and Operator Mono.
[0]: https://en.wikipedia.org/wiki/X-height
Exception: all my spreadsheets are in Consolas (an universally available font in Windows environments).
Did anyone experience the same in the begging and grew to actually like these fonts or was it always a "love at first sight" experience for you that use them?
Later I loaded up some JS code I was working in earlier but without ligatures as the terminal I was using didn't support them. It definitely felt oddly verbose, especially the arrow functions.
I can still go either way, but it's mostly lack of ligature support that keeps from adopting it wholesale. Changing one way or another is a tad disruptive.
Is there any good terminal app that supports ligatures? I tried konsole, but the font looked like it wasn't getting any anti-aliasing and was harder to read as a result.
I love terminator, but it doesn't support ligatures.
What do you use?
[1] http://input.fontbureau.com/
[0] : https://github.com/tonsky/FiraCode/issues/162 [1] : https://github.com/mozilla/Fira
An example from some lua code I'm working on at the moment:
I find that aligning things not only looks better but also makes the differences more obvious. Same code with a proportional font:local hi = buffer:bitfield(4, 4)
local lo = buffer:bitfield(12, 4)
return bit32.bor(bit32.lshift(hi, 4), lo)
It's not a deal breaker (and the offset is small in this case) but I much prefer the monospaced version. Obviously it might also be "Stockholm syndrome" after decades of coding with a monospaced font, I can't say I've really given proportional fonts their chance.
Also many proportional fonts make it hard to distinguish between Il1 or O0, but I guess you could design a proportional font that doesn't have this issue. What font do you use yourself?
The inability to do vertical alignment outside of the left edge of the line is a bit annoying, but honestly I don't miss it that much. If you have enough code that you really, really need to do that, I find it's a code smell indicating that something likely needs to be broken into smaller pieces anyways.
[1] http://imgur.com/a/JiYhD
Another thing I'm considering to adopt from ST is dropping syntax highlighting. If research on highlighting for natural language can be transferred to code (I'm not entirely sure, but I suspect it might), highlighting might actually be harmful to comprehension. The only thing I'd keep is a slightly lighter colour for comments, as these don't have quite the same status as code. Ideally, I think I'd like to have them deemphasised by moving them off to the margin or something like that, but that requires rather more work than rendering them a lighter colour than the rest of the code.
Interesting. Could you share some of that research and its conclusions?
Of course, there are several possible error sources (unfamiliarity with the colouring scheme for example), and whether this can be transferred to reading code is an open question. But I still think it's important to keep the existence of this kind of research in mind when discussing this kind of question (and also the similar question of mouse-driven interfaces vs. keyboard shortcuts), as it easily devolves into strongly held opinions and arguments along the lines of "it stands to reason that $opinion-held-is-true"
In code, I'm frequently tracing back and forth through a block, looking for specific information in different lines. I think that the coloration helps to provide "landmarks" for non-linear traversal of the code. I'd consider color-free code to be more similar to un-punctuated text, than I would consider colored text to be to colored code.
I've tried to look at code without highlighting and I can't read it because the color gives me additional context (metadata?) about the code.
This is one reason I'm a fan of Douglas Crockford's slightly unorthodox style of always beginning comments in column 0, rather than indenting them along with the code. This helps, to a small extent, in differentiating comments from code. Example: https://github.com/douglascrockford/JSLint/blob/master/jslin...
Ideally, I'd prefer to float them to the right margin (suggesting the Lisp style of line comments starting at column 78 or thereabouts, I guess), but this is an acceptable compromise. At first blush it seems to break the flow of the code a bit too much, but I'd probably get used to it reasonably quickly, especially in conjunction with grey comments and black text.
[0] http://input.fontbureau.com/
When I write code that reads more like long-prose, then I do prefer proportionally-spaced fonts myself. This is generally characterized as code with a low density of variables and constants, and lots of control and data structure manipulation. However, when I write code with lots of objects, I tend to prefer monospaced fonts. This is because my personal aesthetic style is to line up groups of related entities and logic; an IDE that gives a modern example of doing this is Eclipse [1].
For IDEs I have to use for a specific project that don't support such formatting, Emacs makes this easy to re-flow so adding a new variable, shortening or lengthening an existing one is still quick. The impact upon version control is still annoying, though; AST-sensitive merge/diff/version-control can't arrive soon enough for me. Fortunately, my code is not regularly inflicted upon others within a team; when I do have to work within a team, I put up with not carrying out my personal preference and use the code formatter that comes closest to the team's formatting standards before checking in.
I do this because it helps me read my own source code quicker. Blocks of entities and logic related by domain and not intrinsically related through the language itself happen to be easier for me to read when I line up like this.
This all goes back to a phase I went through a long time ago when I tried to figure out how to adopt literate programming in all my own work, within the context of an integrated single-source publishing, version control, testing, training, and problem management environment. In my mind's eye, I imagined all the media and activities surrounding a software product related back to the code in some manner, with the code displayable in different contexts based upon the AST and domain-specific hints, and when I made a change in either, I could see and manage the change in the network of related nodes. So if I change how a GUI behaved, then the parts of the User Guide that reference the old GUI, list of users who logged problems documenting confusion about that part of the GUI, etc. would all be automatically flagged. The User Guide would automatically get updated graphics content available from the GUI testing as soon as the testing data was built, the training material as well, and the users would get a note from the support team when the next version was released, detailing the change. I eventually decided that mountain was one I wasn't going to grind down myself anytime soon, so my code formatting is one of the many small ways I preserve that ideal.
[1] https://stackoverflow.com/questions/13936569/eclipse-auto-al...
What I would like is a language-aware editor that can visually align assignments, parameters, etc. without touching the actual whitespace characters. You get 1 tab for indentation (if the language allows tabs) and 1 space for alignment, and the editor takes care of the rest. The raw text would still be readable enough and use fewer bytes for people who prefer to code in a monospace terminal over SSH over an acoustic coupler from a phone booth in rural Texas.
I really, really wish this was available in the editor I fight with every day.
There's a good-sized category of things that have a bit of an adoption cost that I'm assured is worthwhile, but that I don't see a really solid reason to commit to. Proportional fonts is one of those (for me).
What? I can't understand how such large font people can function. I mean, how large (or dense) are your screens? Is that a Macbook thing?
I'm at... something small. Hard to tell exactly, because on my laptop screen, all following fonts look pretty much the same size, while having different configured values:
- IntelliJ - Monospaced, size 12
- Emacs - (:family "Hack" :foundry "unknown" :slant normal :weight normal :height 76 :width normal)
- xterm - xterm*faceName: Hack:size=8:antialias=false
So 8 / 12pt (which one is pt?) and/or 76 somethings. People at work say I'm crazy working with such small text, but frankly, anything larger for me feels like wasting tons of vertical space, which is of short supply given the (IMO completely idiotic) market standardization on 16:9 and 16:10 displays.
Any presbyopic developers care to chime in on what the experience is like? I'm 40, so mine could cross over any time now.
I hate 16:9 too. Please give me back the bottom of my screen that you chopped off.
With 16:10 screens however I think it work rather well, I currently use three 1920x1200 monitors and two of them are vertical, it looks like this: https://svkt.org/~simias/emacs-vertical.png
It's also great for looking at docs.
Well, heck, you shouldn't be programming at all. You're much too old.
(And in case your irony detector is broken, I'm 52.)
Your neurology adjusts pretty quickly. The first few days, your field of view feels limited. After that it feels normal. It was a delight to adjust my font sizes down on all my devices, back to what I would have used at 30 years old.
Code and web browsing (which is really just walls of text) goes on the tall one, everything else on the other one.
The new 15" TouchBar MBPs can drive two 5k monitors. It's amazing for work. Seriously.
For example, I can use a 12pt font on my macbook pro's screen, but have to go up to 16pt on my 4k display at home, and down to 9 or 10pt on the 1920x1024 screens in the office. It's a pain, but... <shrug>
Instead, if you really want to compare font sizes, compare either the height relative to the window, or actual size on a ruler held at arms length while at normal viewing distance. That way you can measure the arc-height of the font - something that translates much better with such a wide variance in displays.
My fonts, corrected for device, all end up being around 1/8" ( tall (for capital letters) on a stick held at arms length.
https://i.imgur.com/dbijNop.png
https://i.imgur.com/cS6EOhZ.png
Depending on your eyes that would be entirely reasonable on an 18 inch lapzilla or preposterously tiny on a 9 inch ultrabook.
That’s... false.
With correct DPI settings – determined by measuring – the same font size equals exactly the same physical size.
That said, I turned off the OS scaling on Windows because apps that didn't support it got scaled by image scaling which resulted in unpleasant blurry messes. As for Linux, I don't think XFCE supports it at all.
On my work rMBP I also use 16px min, even with the OS scaling turned on.
When I was a teenager I used to use 10px fonts, but I tend to use displays at more ergonomic distances these days.
[1] https://fontforge.github.io/en-US/
www.triplicatefont.com
For everyone else, perhaps it should be seen as an editor problem? There's no reason vim can't see that you type != or =/= and replace it on the fly with ≠.
Since it's a bit of a process to rebuild Iosevka, I just bundled the artifacts: https://goo.gl/gsFm8P
(Please excuse the redirection, this got a LOT of downloads and I have a big azure credit so I hosted it there and youw ould not believe what a pain it is to host simple linkable files on Azure).
https://gist.github.com/pcstl/2d9b28a74d6f9254586c2d58d54590...
There are a LOT of problems with that. First and foremost you really do want double character width for these symbols in the iosevka format. Stuff like → is microscopic.
The && also breaks out of alignment. Alignment is the whole reason I am using mono-spaced fonts.
My history: IBM VGA (strange j, h, k, etc.), Courier, Bitstream Vera Sans, Lucida Sans Italics (only proportional font, but it looked great at the time), Consolas, Kids Play.
When coding in Haskell, I used to use the vim-haskellConcealPlus [1] plugin for vim to swap chars being display into nicer unicode chars for various operations.
I'm no longer using it now because it wasn't monospaced and moving around lines was jarring.
If only there's a way to combine the benefits of the two. Monospaced font with ligatures seems to only work for operators that take the same amount of space as their ligature counterpart.