Repository navigation
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @chris-morgan (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Thanks! It's a good step, and it would be better even to bring us closer to what the docs say in |
|
@da-x That's an even better idea. I can look into that, this weekend possibly, if that's fine! |
|
@mandreyel Thanks! |
|
@mandreyel Are you still planning on looking into this? If not, I'd be willing to take a stab at it. |
|
I'm so sorry, lots happened recently and I never got around to this! @z2oh I'd still like to finish this, if you don't mind. But I'll let you know if I can't finish it! |
|
@da-x Alright, I assigned loop keywords to I noticed that |
|
@da-x sorry to bother you... do you have any sort of update on this? I am very much looking forward to improved syntax highlighting 😀 |
|
Apparently I never ended up actually posting this comment, and so it simply sat in the tab in Firefox for a month or two— More precise groups exist, but consensus (between myself and whoever wrote the various parts in the first place) was that distinguishing them didn’t look as good; that’s why we left them, so that you can (However, for reference, I belong to the school of thought that says colour schemes are generally too fancy. A few years ago I threw away my colour schemes and wrote a new one from scratch, which I called “bland”. Keywords are bold, strings are red, comments are italic green, numbers are blue, and that’s about it. I should therefore be considered biased.) |
|
Hi, sorry for the late response. I've done some analysis, and it's hard for me to find reasons to align myself with the previous consensus. My rationale is the following: Being that it is up to the color scheme on whether to allow differentiation on keywords types, and then it is up to the user on whether to utilize it in his or her color scheme (as a side note example, my own color scheme does not (yet!) differentiate loop and conditional keywords from other keywords), combined with the fact that many syntax highlight plugins that come built-in with Vim do allow for this differentiation, then we should allow for this as well in The main reason is consistency. For example, suppose that I was a using the trio of Lua, Haskell, and Rust in the same project, and have configured differentiation for the If the original intention for So let's continue with the changes? |
|
☔ The latest upstream changes (possibly #535) made this pull request unmergeable. Please resolve the merge conflicts. |
I'm writing a vim color scheme and I'd like to be able to differentiate
return,break,continue, and similar keywords from "less important" keywords such asletorimpl. Thus I added a new syntax type calledrustCtrlFlowso color scheme authors can specifically target the control flow related keywords.