linter-pylint icon indicating copy to clipboard operation
linter-pylint copied to clipboard

"Error running Pylint" on Atom

Open cookienut opened this issue 4 years ago • 7 comments

Getting an error while trying to run linter-pylint on atom.

  1. Installed pylint and also installed linter-pylint using $ apm install linter-pylint.
  2. Set the pylint executable path in config for the linter-pylint package (same as which pylint)
  3. Let atom install all related dependencies.

Then console log reads the following trace:

/home/admin123/.atom/packages/linter/lib/linter-registry.js:154 [Linter] Error running Pylint 

Error: Line number (57) greater than maximum line (50)
    at Object.generateRange (/home/admin123/.atom/packages/linter-pylint/node_modules/atom-linter/lib/index.js:162)
    at /home/admin123/.atom/packages/linter-pylint/node_modules/lazy-req/index.js:22
    at Object.<anonymous> (/home/admin123/.atom/packages/linter-pylint/lib/main.js:171)
    at Generator.next (<anonymous>)
    at step (/home/admin123/.atom/packages/linter-pylint/lib/main.js:7)

Can this be fixed ? Am I doing something wrong ?

Screenshot from 2020-07-20 00-55-22

cookienut avatar Jul 19 '20 19:07 cookienut

I have the same very annoying issue.

j2bbayle avatar Oct 06 '20 14:10 j2bbayle

Also getting this. Any idea how to disable?

jamjensen avatar Dec 16 '20 18:12 jamjensen

@jamjensen For me, just re-launching the app didn't work. However, restarting the system made the error go away. So maybe, try that.

cookienut avatar Dec 16 '20 19:12 cookienut

I see this problem as well, and am attaching a simple testcase that reproduces the error for me (Atom 1.54.0 x86, linter 3.3.0, linter-pylint 2.1.1, pylint 3.8).

pylint-testcase.txt

It appears to be provoked by inconsistent indentation in the python file.

To work around the problem, edit linter-pylint//node_modules/atom-linter/lib/index.js in your packages directory and replace this code:

if (colStart > lineText.length) { throw new Error('Column start (' + (colStart || 0) + ') greater than line length (' + lineText.length + ') for line ' + lineNumber); }

with

if (colStart > lineText.length) { colStart = 0 }

mrv20 avatar Jan 27 '21 14:01 mrv20

Thanks for the workaround!

Any idea if this will be fixed in the next versions of this package or atom-linter? I haven't looked closely at the problem, so I'm not sure if the problem lies in one or the other…

j2bbayle avatar Jun 18 '21 17:06 j2bbayle

One issue is for at least some E0001 syntax errors (and maybe others?), pylint is returning a column index of line length + 1, and based on its own self tests, that seems to be the expected return value. I assume this means there's some issue parsing things between one line and the next? There seem to be other errors that produce an index greater than the line length, but I don't know if I could document all of those cases.

atom-linter has a check in the generateRange function to compare the starting index (colStart) with the length of the line (lineText.length) that throws an error if colStart is greater, and there's no way to suppress that error and reset the index to 0 or lineText.length.

The easiest solution would be for atom-linter to allow suppression of that error and setting colStart to 0 and/or the beginning of indentation. I've opened an issue in that project requesting that functionality, so feel free to chime in.

The next easiest solution would be for linter-pylint to have have its own version of a generateRange function. It's only about 50 lines of code, and that would provide direct control over these errors. Might be worth throwing together a PR. Regardless, if linter-pylint wanted to check the column index before running generateRange() it would have to repeat a lot of the logic that is in the generateRange function to get the line length from the buffer.

Hardest would probably be to redefine the length+1 index in the pylint project, even though it seems like an odd convention.

kungfujohnjon avatar Jul 16 '21 15:07 kungfujohnjon

It looks like someone has already submitted a pull request for the E0001 issue, but it hasn't been merged yet. Considering the last merge was 2 years ago, I don't know how imminent a fix is at least on this project.

kungfujohnjon avatar Jul 16 '21 15:07 kungfujohnjon