Open saralilyb opened 7 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:
Provide ligatures for a small set of the most popular infix functions (i.e. %*%
, %in%
, %%
, %/%
, %>%
)
Provide a general ligature (if possible) for any sequence of alphabetic characters that come in between %
and %
. However, even if OpenType supports this, it may have too high a risk of interfering with syntax from other languages.
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.
Wow, the great Hadley jumped in himself 😄 Thanks!
@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
%in% - look no further than LaTeX (actually the semantics speak for themselves to a math person)
%% - I righteously proclaim that wrongs can be righted by translating this to remainder or some variant, with attendant aesthetic challenges
%>% 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.
@bwiernik @traversc Pretty sure it was intended to be extensible ...
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.
@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.
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).
Alternatively, the standard framing characters could resemble something like an ellipses ⋯▷⋯
My two cents:
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
I guess changing this to Fira Code is out of question? if so is there a way to customise this for personal usage?
@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
@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.
@jzadra I’m afraid not. You’re on your own
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.
I want the ligatures to resemble original characters combination (@tonsky)
Then maybe it’s time for an R specific fork...
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 |>
.
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
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)
@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 .
)
the new pipe look so nice aligned with ligature
The new pipe doesn't replace magrittr's pipe - pls don't forget about this
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:
My implementation:
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.
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.
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,
I propose:
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:
Alternatively, mirroring the rigthmost %
might not be necessary- Much of the focus pulling of the % can be addressed by the changes to it
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:
With pipes aligned
%in%
ligature vs in
This should be the ligature for [▷]
, I think.
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:
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
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!
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.
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.
Not a fan of this one... once you see the dick, you cannot unsee it...
Thanks for that 😓😂
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?
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!
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:
(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...
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 🙂
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!
Absolutely agree. Ignore my shit. @tonsky thanks for adding this to a milestone!
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)
@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.
Commenting here to subscribe to updates, and also to suggest this as a possibility:
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:
This is my draft idea, so feedback is welcome, thanks.
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.