Ligatures?

[carlomunguia]

I do not expect this anytime soon, but I want to put it out there : ligatures. Italics & Bold will be great, but I’d rather have fresh ligatures to use in my agave code in the future!

Also, thank you for creating this font. It Oozes unusual monospace beauty & helps your eyes over lengths of time. ✨🌵

[blobject]

Hi, thank you very much for using agave and for your feedback.

I will definitely consider ligatures as they sound interesting for agave, but I have yet to come up with a roadmap for future development. Most likely, I will take a path-of-least-resistance approach to adding more features, and ligatures do seem like good candidates for adding first. I will do some more research.

And just wondering, what kind of ligatures do you use most often? I'm guessing arrows, conjunctives, that sort of thing?

[carlomunguia]

Yes, for all of the math operators, arrows & conjunctives relative to coding.

I became obsessed with finding the right "daily driver" coding font. Agave has become that font for me, and adding ligatures would basically add superglue to my font selection in RubyMine!!! lol

I also love the illusory effect between large and small sizes, how the movement of the font comes alive at smaller sizes! its so cool!

[blobject]

It excites me immensely to hear that agave is being used as a fellow programmer's daily driver. That is, quite honestly, more than I had hoped for when first making the font. Thanks. I will look into ligatures and hopefully come up with designs that preserve agave's quirkiness.

[carlomunguia]

Agave brings my code to life. It's quirkiness is its power in parsing syntax line by line. Can't wait to see the future progress in regard.

[blobject]

I took a brief look at "ligatures for coding" and I must say my opinions on adding them are negative, contrary to my earlier comments above.

Sure, the actual implementation does not seem difficult, but I have trouble weighing the advantages against the potential disadvantages. So unless I am persuaded otherwise, I will have to decline adding coding-ligatures to agave. (Please note, however, that I have little experience using coding-ligatures, so I may be underestimating the advantages.)

These are my reasons (in no particular order):

• There is yet no standard for coding-ligatures.

  • Example: What would be the reason for providing a ligature for === as opposed to some other sequence of symbols? Because JavaScript is popular? But where would I draw the line, and how would I "rank" particular combinations of symbols?
    • I realise this line of reasoning can be extended to arbitrary, even metaphysical, considerations. But what adding ligatures would do in practice is add yet one more level of uncertainty and doubt in terms of design principles.

• Adds semantic complexity.

  • Example: tonsky / FiraCode / issues 751 and 92.
  • Example: Let's say you want to use a bunch of =s to decorate a block of comments, but without ligatures. Simultaneously, you want to use == ligatures in normal conditional statements. What do?
    • Granted, this stems more from a lack of experience with ligatures than from a reason against adding them to agave. But still, similar considerations will ultimately have to figure into the design.

• Adds logistical complexity (possibly following from previous point).

  • We would likely need to supply numerous variants. For example, a variant with <= for C and another with =< for Prolog. (Bad example, I know. The point is that there may be conflicting semantics between different languages and usages.) Or at least provide some convenient way of building user-specific variants.

• Goes against the original design idea of agave.

  • I am hopelessly conservative when it comes to agave's "retro-inspired" design. And I must admit that coding-ligatures just do not evoke that regularity and simplicity we love so much in classic terminal fonts.
    • For instance, I doubt ligatures would get supported in pure virtual console environments (not that outline fonts would either). But if and when they do, I will definitely reconsider this issue :-)
  • Ease of programming was part of the intention behind agave's design. At the risk of sounding ignorant, I believe that fonts without ligatures can still have very high "programmability", as witnessed by agave's various inspirations, like Consolas for instance.

A blog post makes some more complaints against the use of coding-ligatures: https://news.ycombinator.com/item?id=19805053 . Not sure if I agree with everything there, but a few points do make a lot of sense.

In conclusion, I thought that I would like the idea of adding ligatures, but further investigation has proven the opposite, and I hope the above reasoning has been clear. I also don't mean to come across as attacking the use of ligatures. I simply don't think they are a warranted feature for agave, especially given the font's design idea and extent of manpower. However, I am still open to persuasion.

Thanks for understanding.

[carlomunguia]

Putting aside that Agave is already a super cool looking font, part of my attraction to your design is your implementation parameters of the glyphs ie Power of 2, the golden ratio. Applying these design parameters seems to add the mysterious, flowing effect Agave seems to produce.

In many ways, your considerations & then rejection of ligatures further reinforces why I dig Agave so much. To me, the main draw of enabling ligatures with a font is to make the Math & Block expressions flow a bit easier on the page. They also tend to decrease, say, ES6 linter issues when dropped into a large codebase. But your considerations are very clear on what could quickly spoil what makes Agave so great.

I am of the same mind that the adherence to the spiritual design of Agave is the correct path forward, whether that includes ligatures in the future or not. Ligatures do tend to be divisive, as do Italics, and could add semantic complexity to an already great design.

There are certain languages that rely on the implementation of ligatures much more than others ie Haskell, Clojure etc (primarily functional programming languages). But obviously these are niche cases & hard to justify in a larger scope of a coding font lifecycle.

[blobject]

Despite not having used ligatures for coding, I can sense the appeal, and the general demand for them is obvious (FiraCode has almost 10x as many github stars as FiraMono -- holy moly).

To me, the best method of adding ligatures to agave would be as an optional feature or a fork. But I hesitate to lead in such a development unless I find more time and/or see demand from more users. And as for the "core" agave, I must stand by my last comment.

In the meantime, I would like to further investigate the "flow of math & block expressions" that you mention. I did make an effort to adhere to metric uniformity with regards to math symbols and brackets, etc. in the ASCII plane, but if there is room for improvement there, even without the use of ligatures, I would be more than willing to implement it.

In any case, your feedback and remarks are very helpful, so thanks again.

[carlomunguia]

I found your font in the following link, a test drive site for a majority of the programming fonts used :

http://app.programmingfonts.org

Agave stands out right away, with perhaps a bit of spiritual genealogy to Fantasque Sans Mono & DaddyTime Mono(the latter having Exceptionally oversized operators & brackets!).

You will notice very few of them possess ligatures, and the ones that do usually pair them equally with italics / cursive italics. So there is a sound argument that ligatures are at best Optional parameters to tack on depending on project use.

If I can aid in any kind of problem solving for your project in any way (also for the Ino typeface), let me know, I would be glad to help.

[carlomunguia]

Also, something I was thinking about - a what if...

What happens to Agave when using the Silver Ratio for traits? Would the results be different enough to yield a sister font? Would it yield a "softer" agave?

Food for thought indeed!

[blobject]

That's pretty interesting. Actually, part of the reason I want to make ino is to parameterise metrics such as these, using metapost (thank you Knuth!). But research/development on that front has so far been embarrassingly slow.

Applying the silver ratio to agave, as it is now, my guess is that things will look just a bit stubbier/boxier (0.618 vs. 0.707 = 1/sqrt(2)). I also get the feeling that agave looks satisfactory right now only because of the peculiarity (read: divinity) of the golden ratio. I think any other ratio will make things slightly wonkier. Well, actually, who knows.

Thank you for sharing that page. It's awesome.

As for help with development, I can't think of anything specific right now, but of course you're free to fork agave and try adding ligatures to it or modify it as you wish. I could maybe give a few pointers in terms of design if you're interested. But to be honest, I am a complete amateur in type design and the scheme I followed is incredibly naive, as you may have gathered from the website. Oh, if you are familiar with using metapost, I would appreciate any info.

[carlomunguia]

There are a million monospace fonts we could use to program. Hell, Susan Kare's original Monaco for the mac is still great to use.

Agave is truly different, I believe that. I TRIED going back to my other daily drivers.
I can't, Agave is simply too cool & functional (ie eye strain, legibility)! lol

Doing a silver ratio edition of Agave may be interesting as a side project, I will consider what I could do to make that achievable. I'm looking over Metapost now and I will give insight if I can on what you may or may not know.

[blobject]

I noticed this project that combines agave with fira code ligatures: https://github.com/pavel/agave-code

[blobject]

As I most likely won't be implementing ligatures for this font, I'll close this thread.