-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Better error ranges for classes and functions #5466
Comments
@cdce8p Do you want to fix this by changing the if isinstance(node, nodes.ClassDef):
end_lineno = lineno |
I think it should be done in pylint: the end lineno from astroid is accurate and useful (maybe used in other libs too). The current issue is linked to the way pylint needs to display errors for class and function. |
I agree, we shouldn't change the Thinking out loud for a moment, it should be somewhat strait forward to do some basic string parsing. Maybe it would make sense to modify the For a start, it would already be an improvement to modify |
Highlighting entire code block is very distracting, to be honest. A lot of unnecessary highlighting is done to communicate something very simple or something that the developer choses not to change. Old behavior (highlight just the beginning of the affected line) was concise and effective enough. Please at least provide an option to change this behavior via settings. Thanks! |
@cdce8p Have you thought about how to go about this? I actually struggled to find an easy and quick implementation to either 1) find the end of the class or function definition or 2) find the end_column of the first line of a definition. Either would work for this I think. |
Instead of adding some new attribute for the The next steps and challenges
Where do I need help?
Footnotes
|
Lot to unpack here.
Although I like making the
I trust you're thinking about this carefully as you always do with breaking changes 😄
This should be fairly easy with a simple script/print statements on the test suite. I'm happy to help here.
Perhaps it would be good to discuss a possible longterm roadmap for |
Btw, perhaps in the meantime we should change |
I'm certainly still open for ideas how to do it better, maybe even without a breaking change. However, what I've found while thing about it is that contextual it would make use The main reason is probably that we already do that in other places ( Furthermore, an
Just a rough list of the top of my head. (only the breaking changes - for plugins)
Additionally, update the position information for the
That would only make sense if we want to do a |
Okay! I just wonder if there are differences between assigning with
👍
Shouldn't be too much work right? Just this in if isinstance(node, nodes.ClassDef):
node.end_lineno = node.lineno
node.end_colnum = node.colnum + 2 Or whatever the right attribute names are. Imo, that could go in |
A possible workaround, at least for VS Code highlighting issue, would be some command line argument that would disable sending |
I'm thinking about moving this to 2.14 because of the amount of work involved and the number of duplicate issues we must handle that are already fixed in main and could be released :) |
@kovla would an highlight of |
@Pierre-Sassoulas Thanks for mentioning this. If the idea is to simply convey that there is a mistake in that line/section, underlining the first symbol (previous behavior) is the most minimalistic solution. As a user, I will explore the issue once, decide if I want to correct it, and after that all communication about it becomes merely a distraction. Hope this way of explaining it makes sense. Sometimes I would look at unresolved issues "in batch" for the entire script, e.g. a sort of final review before a commit. In that case, I typically pay more attention to the code map highlighting, or simply to the textual list of issues. Again, extensive highlighting is not offering much advantage in this scenario. All in all, it might be a matter of subjective preference, and, pragmatically, both approaches work. My personal preference, not that it should matter, would be to go for the minimalism (it may also help keeping underscoring consistent for different issues). |
The main issue, and I think we agree on that, is highlighting the whole class / function (without reason). That will be resolved either way.
That's a subjective preference IMO. Maybe something a dedicated VS Code addon can explore? #5796 |
Reopening it to collect feedback after we release 2.13. The current changes are definitely a good start, but we might still be missing some things. |
Have this feature added? |
How to install pylint-2.13-dev? |
With pip you can do |
The
|
Thanks a lot!! |
@cdce8p should we close now ? It seems the change was good enough that we did not get any more feedback :) |
I'm going to close this as we're nearing the end of the |
1 similar comment
I'm going to close this as we're nearing the end of the |
There are still some edge cases which can be improved, like #6606. |
The error ranges for
Class
andFunction
nodes should be improved. At the moment they span the whole length of the corresponding block which isn't ideal, especially once error range support in VSCode is added.Ideally, those should only highlight the actual class or function name.
The text was updated successfully, but these errors were encountered: