Operator highlight extended and improved#50
Merged
Hi-Angel merged 4 commits intoMay 9, 2025
Conversation
What face is the most appropriate is arguable. Emacs 29.1 has "operator-face", but it's unavailable for older Emacs, and even for newer versions it's just "nil", so no highlight. Kinda pointless face. The current "variable-name" is definitely wrong though, because operators are far from being variables. And there's a separate "color-identifiers-mode" which uses this face to highlight similar variables, and that would work wrong for purescript-mode. Thus, replace the highlight to "builtin".
Hi-Angel
force-pushed
the
font-lock-operator-improvements
branch
from
1fb5e59 to
c84353e
Compare
Member
Author
|
CC: @niklas hi, I know you're using the mode, so I'm pretty sure you've seen the mishighlight, like with the Either way, I wrote some tests too, hopefully I didn't miss anything 😊 |
For example, the tuple construction `1 /\ 2` was weirdly half-haighlighted before this commit, because it wasn't covered by the "operators regexp" and was getting caught by some other rule. Fix that. For inspiration, I looked at the regexp from the official Atom purescript highlight https://github.com/purescript-contrib/atom-language-purescript/blob/d17eee55b12c140e8a1a750cce7e5aa9b09653c2/src/purescript.coffee#L32 that one works a bit differently, it excludes chars from class. AFAIK Emacs can't do that, so instead I just enlisted the symbols. One thing I did differently though is including colon, because it is a valid operator in PureScript (for List), I think Atom has a bug in their regexp.
Hi-Angel
force-pushed
the
font-lock-operator-improvements
branch
from
c84353e to
49e0fae
Compare
The (,) and (->) don't have much use in PureScript, nor in Haskell for that matter. In Haskell (,) was a prefix notation for tuple construction, but in PureScript this operator isn't a thing. Both trigger "syntax error" in PureScript (and (->) doesn't work even in Haskell). Indeed a debatable rule. Let's just remove it.
Backticks don't need to be escaped.
Member
Author
|
Okay, I've used it for a while, everything seems fine. Merging. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prior to this PR some operators weren't correctly highlighted. One example is the tuple construction "1 /\ 2", it has weird "half-highlight", because it's not covered by operators and then gets caught by some other rule.
With this PR such highlight is hopefully fixed. For inspiration, I looked at the regexp from the official Atom purescript highlight. It works a bit differently: it excludes chars from class. AFAIK Emacs regexps can't do that, so instead I just enlisted the symbols. One thing I did differently though is including colon, because it is a valid operator in PureScript (for List), I think Atom has a bug in their regexp.
Another change being done is I replaced the underlying face from
variable-name-facetobuiltin-face. It is open for debate which face is the best, butvariable-nameis just wrong because it's far from what's actually being highlighted; and the face is used e.g. by color-identifiers-mode to find identifiers (variables or constants), which operators are not.