-
Notifications
You must be signed in to change notification settings - Fork 750
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
Feature/upgrade powershell #1213
Feature/upgrade powershell #1213
Conversation
@aaroneg The comment |
Ah thanks @ashmaroli |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know if you have any questions about the comments!
Ignore, as I figured out what you were doing here now. |
sure. Co-Authored-By: Ashwin Maroli <ashmaroli@users.noreply.github.com>
… into feature/upgrade-powershell
@gmckeown Sorry, bringing the discussion back to the main PR since we've resolved the other stuff. I discovered that a problem with my lexing logic was the parsing of attributes. I've since fixed this but do not think the list in @jpmarceau Sorry to drag you into this but since I now know you use the PowerShell highlighting, too, do you have any thoughts? |
It does contain all of the cmdlet binding attributes, so I guess the question is whether you're expecting other attributes to be included? Does It is formally considered an attribute, but should we distinguish between cmdlet binding attributes and function parameter attributes? They're certainly not interchangeable -- you can't put |
@gmckeown We also have |
I think yes. Did @aaroneg include CmdletBinding in there initially? Maybe there was a reason? |
lib/rouge/lexers/powershell.rb
Outdated
rule %r/(function)(\s+)(?:(\w+)(:))?(\w[-\w]+)/i do | ||
groups Keyword::Reserved, Text::Whitespace, Name::Namespace, Punctuation, Name::Function | ||
end | ||
rule %r/(?:#{AUTO_VARS})\b/i, Name::Builtin::Pseudo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pyrmont I just want to re-iterate that I think this is an over-simplistic way of identifying the automatic variables -- I did it as a quick test locally, but it's not going to correctly highlight them in strings and possibly in other contexts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. Good to know. I should probably move the test to the :variable
state.
@gmckeown It was in there from the beginning (@aaroneg took it out in the initial commit but he later put it back). I think we can take it out and highlight it like VSCode does. |
That works for me! |
@gmckeown I'll see if @jpmarceau has any thoughts. He very quickly noticed an error in the PowerShell lexer in 3.5.0 so might have a helpful perspective. It's looking pretty close to merging to me. |
@pyrmont Just spotted an oddity in the visual sample with the latest lexer: Not sure why rule %r/([A-Za-z]\w+)/ do |m|
if ATTRIBUTES.include? m[0]
token Name::Builtin::Pseudo
else
token Keyword::Type
end
end I guess |
@gmckeown I'm away from my computer but I'm not sure. I'll have a look later this evening! |
@gmckeown I'm a moron. I was mashing the elements in the |
lib/rouge/lexers/powershell.rb
Outdated
@@ -14,8 +14,8 @@ class Powershell < RegexLexer | |||
|
|||
# https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_commonparameters?view=powershell-6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For accuracy, should now change this comment to:
# https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_functions_cmdletbindingattribute?view=powershell-6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have made the change (only found out that GitHub allows a direct edit and commit from the UI...).
@pyrmont thanks for asking but sadly I can't really offer much input here. I quickly spotted the issue with 3.5.0 because it was causing my deployment to fail, but other than that I don't have enough expertise with your project to be of much use. |
@jpmarceau No problem! Just wanted to check :) |
Thanks to everyone that contributed as part of this PR. We have a far more robust lexer as a result :) If you spot any problems, please always feel free to file an issue! |
This should fix or make moot the following issues:
closes #640
closes #966
closes #1041
closes #1208
closes #1209
closes #1210
This should make it unnecessary to merge:
closes #967
I would like to thank @miparnisari for caring enough to open a PR ❤
It does NOT fix, but partially addresses:
#1025 , and it would be nice to get some more expert help on this one.
It doesn't handle two types declarations on the same line for some reason, and perhaps someone more accomplished with rouge can help me figure out why. Perhaps @jneen ? ( See the first few lines of the 'Add-Extension' function in the sample output )
It also adds support for comment based help ( https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_comment_based_help?view=powershell-6 )