-
Notifications
You must be signed in to change notification settings - Fork 26
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
Resolve named character operators #118
Comments
|
My project makes heavy use of |
@simonkeys At the moment and for the foreseeable future, I have to explicitly ban the usage of named character operators. That means, the plugin recognizes them, knows that these named characters are operators (and cannot be part of symbol names), and marks them as unsupported. The solution is to use
is evaluated if someone reads your code, while However, the main reason I don't work on this is that as of today the Wolfram Language still has no official language specification (grammar). The front end (what you type in the notebook) and the kernel have differences in interpreting input code. Therefore:
So right now, the only advantage of supporting named character operators would be that people can write them infix as you want. I hope you understand that the price tag on this feature is too hight right now. I left this issue open so that one day, when we have a clear specification of the Wolfram Language, and I'm not working a full-time job in an entirely different branch, I can come back to it 😁. |
Currently they are considered part of a symbol name if there is no space. Which usually does not happen because the space is added automatically when pasted.
With exception of e.g.
\[Transpose]
which is pasted without spaces.Most important:
\[Transpose]
\[ConjugateTranspose]
\[Conjugate]
Important:
\[UndirectedEdge]
\[DirectedEdge]
and friendsLess important because they are converted to ASCII when pasted:
\[Rule]
,\[LeftDoubleBracket]
and friendsrelated: #117
The text was updated successfully, but these errors were encountered: