Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Difficult to access symbols used in public API #87

Open
Datseris opened this issue Aug 22, 2022 · 1 comment
Open

Difficult to access symbols used in public API #87

Datseris opened this issue Aug 22, 2022 · 1 comment

Comments

@Datseris
Copy link
Member

One of the main API functions, transferentropy, has keyword arguments based on unicode symbols that are hard to access. I am specifically referring to 𝒯.

Some developers recommend to not use unicode at all for public API. E.g., SciMLStyle:

Unicode is fine within code where it increases legibility, but in no case should Unicode be used in public APIs. This is to allow support for terminals which cannot use Unicode: if a keyword argument must be η, then it can be exclusionary to uses on clusters which do not support Unicode inputs.

Personally, I think that Unicode should be okay to use as long as it is easily accessible with tab completion, and immediatelly obviously which symbol should be used. Even if the terminal cannot display it and uses a box for it, Julia will still properly use it as a keyword. So that's why I am not so fanatically opposed to unicode.

However, I am not sure how to input 𝒯, but I am sure that τ is 'tau. I think we should consider a different symbol for the scripted capital T.

@kahaaga
Copy link
Member

kahaaga commented Aug 22, 2022

𝒯 and squiggly friends can be obtained by tab completion by prefixing \scr to whatever letter you want in scripted form. Other similar symbols are achieved by using the \frak- and \bi prefixes. Once you get used to this (and remember it), it's just as fast as using \tau.

See the overview at https://docs.julialang.org/en/v1/manual/unicode-input/.

However, if a user doesn't regularly use these commands, I see that it can be cumbersome to have to use this symbol. I'm okay with changing it to something else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants