tonsky / FiraCode

Free monospaced font with programming ligatures
SIL Open Font License 1.1
77.31k stars 3.1k forks source link

Ligature request: %>% pipe operator in R #473

Open saralilyb opened 7 years ago

saralilyb commented 7 years ago

We use the pipe operator %>% a lot in the Tidyverse set of packages in the R programming language. It's a way of stringing together many functions, converting them from prefix to infix. It would be really nice to have a pipe ligature.

screen shot 2017-08-10 at 12 24 36 pm
hadley commented 6 years ago

In R, %% is used to create custom infix operators, and technically any sequence of characters can come in between the two % (even whitespace, although that's obviously a bad idea) . Given that, I'd recommend either:

Personally, of the options presented so far, I like @kelleyvanevert's suggestion to use smaller percent signs the best. I think using °▷° is too risky as it looks very different to %>% and it's is likely to confuse people.

msberends commented 6 years ago

Wow, the great Hadley jumped in himself 😄 Thanks!

BStudent commented 6 years ago

@hadley, this touches on an issue concerning (what I'll dub) "mathematician" and "designer" viewpoints to reconcile, some things seem obvious while others seem hard (and adherents don't always agree which is which). The examples I'd offer as a math camper are

  1. %in% - look no further than LaTeX (actually the semantics speak for themselves to a math person)

  2. %% - I righteously proclaim that wrongs can be righted by translating this to remainder or some variant, with attendant aesthetic challenges

  3. %>% is a special challenge ... One can almost justify changing pipe semantics: really, this is function composition in reverse, to wit: y <- x %>% h() %>% g() %>% f()

Is in most cases effectively function composition: f(g(h(x)))

In many other branches of math this is written with the circle operator:

f o g o h(x)

(Forgive me, I am doing this from a phone so I have to use lowercase o as a kind of circle operator purchased on sale at Walmart)

Other than Maybe for %in% I do not claim to have all the answers much less good ones, and there are perhaps counter-examples to my interpretation of the pipe as function composition.
But I do think that with existing sins - such as referring to remainder as modulus with casual abandon - destroying the very fabric of society, we have some obligation to maintain a consistency between Computer Science and the other branches of Mathematics, or at least not make the situation worse.

BStudent commented 6 years ago

@bwiernik @traversc Pretty sure it was intended to be extensible ...

bwiernik commented 6 years ago

The fundamental concern of a typeface is making text easier to read and, for programming typefaces, making it easier to identify errors. Things that obscure the actual underlying characters, like °▷° or run counter to this purpose.

BStudent commented 6 years ago

@bwiernik I agree with your statement of purpose ... and pipe is a different animal from %in% and %% ... what would be nice from both a ligature standpoint and to your concern is if all languages with a pipe-like operator could agree on a single ligature for the representation, independent of the horrifying assortment of ascii characters they have settled upon for the individual compilers/interpreters.

andrewcstewart commented 5 years ago

Considering that %...% frames every type of custom operator, I wonder if they could be rendered as standard bookends to any such customer operator... something more akin to [>], except as a complete box (or something) framing the actual operator symbol. The left and right % would always render into the same framing characters, and the internal operator symbols would include both a _ floor and ceiling.

So in the case of %>% this could render to something like [ ▷ ] (though within a full rectangle). image

image

image

image

image

image

image

image

image

Alternatively, the standard framing characters could resemble something like an ellipses ⋯▷⋯ image

hanowell commented 5 years ago

My two cents:

  1. A ligature that won't confuse programmers who know the language will be good. It should feel natural. That is why the arrow ligature works so well and why the de-emphasized percent symbol option works so well.
  2. Someone said that the centered de-emphasized percent symbols are "jarring" and suggested percent symbols be placed on bottom line. I disagree. This will make the symbol harder to distinguish from other symbols. The triad of shapes of different sizes and the symmetry of the centered percent symbols makes those ligatures pop out in the test that I saw. Making the symbol easier to read and distinguish from other symbols is a plus.
kklot commented 5 years ago

as Fira already has ligatures for those symbols inside % such as %->% it seems to be a wasting of time trying to come up with new symbols every time. Following the deemphasise ideas, replacing the % sign with that of Courier New font look pretty readable for me, even for those cases without ligature like the modulo

Screenshot 2019-06-13 at 13 54 06

I guess changing this to Fira Code is out of question? if so is there a way to customise this for personal usage?

tonsky commented 5 years ago

@kklot you can open ttf/otf files in any font editor and change them to your liking. To rebuild from sources there is https://github.com/tonsky/FiraCode/blob/master/script/build

jzadra commented 5 years ago

@kklot you can open ttf/otf files in any font editor and change them to your liking. To rebuild from sources there is https://github.com/tonsky/FiraCode/blob/master/script/build

Is there any documentation about how to do this for contributors? I looked around the files in this repo but didn't see anything like that.

tonsky commented 5 years ago

@jzadra I’m afraid not. You’re on your own

msberends commented 5 years ago

as Fira already has ligatures for those symbols inside % such as %->% it seems to be a wasting of time trying to come up with new symbols every time.

Ever since tidyverse, the %>% is really something else, that could use a lot more dedication than what you’re suggesting. I think that’s clear from this (way too long) thread and the ones of #41 and #195.

msberends commented 5 years ago

I want the ligatures to resemble original characters combination (@tonsky)

Then maybe it’s time for an R specific fork...

msberends commented 3 years ago

The relevance of this discussion will perish, since we now know base R will come up with a pipe in their next version as a drop-in replacement for the magrittr/dplyr pipe.

The pipe will probably be |>.

bwiernik commented 3 years ago

The pipe is only one of many inline operators in R. Anything between two % would be better with a ligature.

(Last I read, the base R pipe was not planned to have the same behavior as the magrittr pipe unfortunately)

Edit: see here for the major incompatibility https://twitter.com/bmwiernik/status/1334853345966780421?s=21

msberends commented 3 years ago

Whatever you like. This is the actual implementation and it looks like perfect drop-in to me: https://github.com/wch/r-source/commit/a1425adea54bcc98eef86081522b5dbb3e149cdc

(off-topic mode off)

timgoodman commented 3 years ago

@bwiernik It looks like instead of writing y %>% f(x, .), you'll be able to write y |> \(.) f(x, .) (or choose a different argument name instead of .)

kklot commented 3 years ago

the new pipe look so nice aligned Screenshot 2021-01-28 at 12 14 31 with ligature Screenshot 2021-01-28 at 12 17 44

strazto commented 3 years ago

The new pipe doesn't replace magrittr's pipe - pls don't forget about this

strazto commented 3 years ago

Hi - I made something like @kelleyvanevert 's suggestion for "whacky" percents in my own fork -

Yes, @timgoodman, that's an excellent suggestion, I think it looks good because it's very clean :) And widening the > does seem like the Fira Code think to do, and it looks good:

fira_r_3

My implementation:

image

The actual glyphs, spacing & size certainly need work - These things look great blown up but get teensy when viewed at 12pts it turns out, and the spacing on the pipes needs to be increased.

Personally, @kelleyvanevert 's suggestion for "whacky" percents (i personally think of them as "bookend" percents) has been my favourite so far.

Discussion of approach of bookending in general

I like the idea of "bookending" the enclosed operator in general, but whatever is done at least needs to suggest the underlying character.

In the vein of @andrewcstewart 's comment:

Considering that %...% frames every type of custom operator, I wonder if they could be rendered as standard bookends to any such customer operator... something more akin to [>], except as a complete box (or something) framing the actual operator symbol. The left and right % would always render into the same framing characters, and the internal operator symbols would include both a _ floor and ceiling.

List of proposed sketches by andrewcstewart > So in the case of `%>%` this could render to something like `[ ▷ ]` (though within a full rectangle). > ![image](https://user-images.githubusercontent.com/1420654/57115753-9c890400-6d05-11e9-8870-bec509ba885d.png) > > ![image](https://user-images.githubusercontent.com/1420654/57115778-d0642980-6d05-11e9-988d-dcd8905485a1.png) > > ![image](https://user-images.githubusercontent.com/1420654/57115909-862f7800-6d06-11e9-8894-d578e80e59e4.png) > > ![image](https://user-images.githubusercontent.com/1420654/57115940-cd1d6d80-6d06-11e9-8365-defc8af3d3b6.png) > > ![image](https://user-images.githubusercontent.com/1420654/57116051-88460680-6d07-11e9-9219-897fb0293ed0.png) > > ![image](https://user-images.githubusercontent.com/1420654/57116068-a6136b80-6d07-11e9-948a-f4a4c50bc384.png) > > ![image](https://user-images.githubusercontent.com/1420654/57116099-dc50eb00-6d07-11e9-8984-831ce612a2de.png) > > ![image](https://user-images.githubusercontent.com/1420654/57116187-731da780-6d08-11e9-862b-df74f96a40c1.png) > > ![image](https://user-images.githubusercontent.com/1420654/57116278-fb9c4800-6d08-11e9-8f4c-6881648554a4.png) > > Alternatively, the standard framing characters could resemble something like an ellipses `⋯▷⋯` > ![image](https://user-images.githubusercontent.com/1420654/57115632-f0471d80-6d04-11e9-9d50-8076d9dd2d20.png)

I like the principle of the suggestion, but none of the proposed ligatures do a lot to suggest the underlying characters. For me, that's a problem,

Proposed bookend that's evocative of % sign

I propose:

image

To describe it:

The above shows two alternatives, either a fully vertical stem on the % , or a diagonal stem with a steeper gradient on the % .

Personally, I think a diagonal stem tracks better as its more suggestive of the underlying character.

To extend this:

image

Alternatively, mirroring the rigthmost % might not be necessary- Much of the focus pulling of the % can be addressed by the changes to it

strazto commented 3 years ago

Here it is if you want to try it out:

https://drive.google.com/drive/folders/1NAqWx8QT2KS-MrwRyFCUuaFvGpq4mP-b?usp=sharing

A few iterations of this concept:

image

image

With pipes aligned

image

%in% ligature vs in

image

RubenVerg commented 3 years ago

sample 1

This should be the ligature for [▷], I think.

kalaschnik commented 2 years ago

R finally got a native pipe: https://www.r-bloggers.com/2021/05/the-new-r-pipe/ Which is: |> and Fira Code renders this as:

image

Due to the character sequence |>, I would propose that magrittr implementation (%>%) should render a similar ligature, so that a user can identify "pipes", but is also able to tell if it’s the base R implementation the tidyverse one. So maybe the proposal from @BStudent makes the most sense now: https://github.com/tonsky/FiraCode/issues/473#issuecomment-385230094

adRn-s commented 2 years ago

I'm really looking forward to these ligatures. Even if they would make my R coding look like an alien sci-fi movie, they're better than nothing and surely any other R programmer will agree with me that even the worst-looking of all of these (whichever that is) is better than not having the ligature at all... any lack of aesthetics is more on R side (having to implement custom operators with 3 characters, etc.).

Sorry for necrobumping the issue, @tonsky, but since your last comment seems to be years old... Can you update/ expand your considerations on this? Thanks!

jzadra commented 2 years ago

Yes, I too am still hoping for a pipe ligature! This is my vote:

This preserves the % and the directionality, but also the concept of "pipe" in that it has an opening for the data to flow through.

image

kalaschnik commented 2 years ago

Not a fan of this one... once you see the dick, you cannot unsee it... Moreover, it is visually far away from the native pipe ligature. Since both pipes achieve the same thing (at some point), it makes sense to both pipes share visual features. And since the native pipe (|>) was there first and is fixed in its design (see https://github.com/tonsky/FiraCode/issues/473#issuecomment-974677495), magrittr’s pipe must submit to it. Just my thoughts on that.

msberends commented 2 years ago

Not a fan of this one... once you see the dick, you cannot unsee it...

Thanks for that 😓😂

tonsky commented 2 years ago

I guess I can make a stylistic set for smaller percentage. Rest of the suggestions change the glyph too much, and I want it to remain recognizable. Would that make everyone happy?

Screenshot 2022-02-16 at 15 04 24
jzadra commented 2 years ago

I like a connected glyph so that it looks like a single character vs 3 characters. But I'll be happy with anything, thanks for your work on this!

kalaschnik commented 2 years ago

I know this does not represent three characters in one glyph, but having the native pipe in mind, with the idea that magrittr’s pipe should be visually similar to the native one; yet, distinct; maybe this:

image

(that is the native pipe rendered in Fira Code retina with scaled-down percentage sign circles)

feel free to hate it, I am not sure what my feelings are about it anyway... but I got @jzadra point, that I would be nice to have something more ligature-like. Three disjunct characters making a glyph feels wrong somehow, yet better than nothing...

msberends commented 2 years ago

This has been a discussion for almost 5 years now, with numerous suggestions, ideas and opinions.

Can we please agree on the suggestion of the font designer @tonsky of today? Would help us all to actually get somewhere 🙂

jzadra commented 2 years ago

This has been a discussion for almost 5 years now, with numerous suggestions, ideas and opinions.

Can we please agree on the suggestion of the font designer @tonsky https://github.com/tonsky/FiraCode/issues/473#issuecomment-1041526123? Would help us all to actually get somewhere 🙂

Agreed. Like I said, I'll be thrilled to have anything, and I love Firacode so I support whatever @tonsky feels is best!

kalaschnik commented 2 years ago

Absolutely agree. Ignore my shit. @tonsky thanks for adding this to a milestone!

ryandward commented 8 months ago

I wonder if it would be possible to write some kind of theme, in the interim, just to hide the %s on valid syntactic markers and just bold/capitalize the intervening symbol or something.

I wonder how hard this could be for vs-code or r-studio?

dataframe %>% filter(value %in% array)

could be rendered as


dataframe > filter(value in array)
strazto commented 8 months ago

@ryandward

I wonder if it would be possible to write some kind of theme, in the interim, just to hide the %s on valid syntactic markers and just bold/capitalize the intervening symbol or something.

I wonder how hard this could be for vs-code or r-studio?

Probably not that hard, but does hiding characters with syntactical significance actually improve your code readability?

Personally I don't think hiding the glyph altogether is a particularly good idea, however, my experience is that it wasn't that hard to implement a new ligature, I think I just used the trial version of the Glyphs (Mac only) app to make my variation of this ligature.

Just to reiterate, I've implemented a version of this ligature that you can download and install: https://github.com/tonsky/FiraCode/issues/473#issuecomment-848437541

I'm not saying it's the canonical version, or even good, but I think it's better than nothing, and certainly better than hiding characters that change your code's meaning.

bwu62 commented 2 months ago

Commenting here to subscribe to updates, and also to suggest this as a possibility:

image

The exact proportions should obviously be fine tuned more but I think this might be a good starting point. The ligature is both identifiable as %>% but also cohesive as a single unit.

Other iterations that could be considered if people think the ligature isn't clear enough:

  1. The circles in the percent symbols can be slightly horizontally offset from each other if desired.
  2. The bars in the percent symbols (i.e. just the first and last third of the long line) can be slightly sloped.
  3. Both of the above?

This is my draft idea, so feedback is welcome, thanks.