You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another attempt at #45 and #57, namely to properly highlight docstrings as comments.
For now, this implementation is very ugly, but it actually works. It only highlights things that should be docstrings without touching other types of multiline strings. This is accomplished by checking for : characters and combining that with nextgroup=pythonDocString to interpret the first directly following multiline string as a docstring. Another case is added for the first multiline string appearing at the top of the file.
The implementation is messy right now to work around a specific problem. Any pointers on how to solve this more elegantly are greatly appreciated. The problem is that nextgroup=pythonDocString skipempty will skip newlines, but not spaces in its search for the docstring, and so it will only find it when the docstring starts on the first column of a line. For now, the workaround is to match +^\s*"""+ as a docstring, i.e. also match the leading whitespace, but this causes the docstring rule to have precedence over the normal +"""+ multiline pattern. Ideally, the multiline rule should take precedence and have this precedence temporarily overwritten by the presence of a : mark.
This seems to work for me, but I needed to add nextgroup=pythonDocString skipempty to pythonRun and pythonCoding to get the module-level docstrings to work when a shebang or an encoding thing is present at the top of the file.
My colorscheme has an aggressive String highlight, so adding huge docstrings to my code has been making my eyes want to explode. This PR saves me a lot of headache - literally, thanks!
Is this PR still under review? Rending docstrings as regular strings in the code as the same color is an eyesore for me.. would love to see this merged!
last commit to this repo was 5 years ago. I guess this is dead. You could do what I did and fork this repo and merge in all the PRs you like.
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
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.
Another attempt at #45 and #57, namely to properly highlight docstrings as comments.
For now, this implementation is very ugly, but it actually works. It only highlights things that should be docstrings without touching other types of multiline strings. This is accomplished by checking for
:characters and combining that withnextgroup=pythonDocStringto interpret the first directly following multiline string as a docstring. Another case is added for the first multiline string appearing at the top of the file.See https://gist.github.com/wmvanvliet/36471bb456151d93b86c402b64684b0a for a bunch of challenging test cases.
The implementation is messy right now to work around a specific problem. Any pointers on how to solve this more elegantly are greatly appreciated. The problem is that
nextgroup=pythonDocString skipemptywill skip newlines, but not spaces in its search for the docstring, and so it will only find it when the docstring starts on the first column of a line. For now, the workaround is to match+^\s*"""+as a docstring, i.e. also match the leading whitespace, but this causes the docstring rule to have precedence over the normal+"""+multiline pattern. Ideally, the multiline rule should take precedence and have this precedence temporarily overwritten by the presence of a:mark.