Error: Column start (16) greater than line length (15)

[miketheman]

Error: Column start (16) greater than line length (15)
    at Object.rangeFromLineNumber (/Users/miketheman/.atom/packages/linter-flake8/node_modules/atom-linter/lib/index.js:179:11)
    at extractRange (/Users/miketheman/.atom/packages/linter-flake8/lib/main.js:49:18)
    at Object.<anonymous> (/Users/miketheman/.atom/packages/linter-flake8/lib/main.js:194:25)
    at undefined.next (native)
    at step (/Users/miketheman/.atom/packages/linter-flake8/lib/main.js:9:273)
    at process._tickCallback (internal/process/next_tick.js:103:7)

Using linter-flake8 2.0.0

[BeyondTheBoundary]

Yup. Very annoying. Confirm.

[LordZane]

Same thing for me

[miketheman]

For any others that find this issue, I implore you to use the 👍 reaction on the original issue, instead of commenting - comments send emails to everyone on the chain and have little value.

If you have further debug/fix details, please do comment with them.

[ghost]

I have found a decent workaround that will suppress the error and allow linter-flake8 to function without any negative side effects.

Open file: .atom\packages\linter-flake8\node_modules\atom-linter\lib\index.js and scroll down to line # 178

Replace:

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

With:

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

Before applying this workaround I was constantly being spammed with the error message discussed in the first post and linter-flake8 would not function at all. However, after applying the aforementioned changes to index.js, I am now using linter-flake8 without any issues.

Disclaimer: This is, at best, a cheap hack to keep things glued together until the project developers are able to update the plugin with a proper fix.

[momitrahman]

Thanks @michaelhx . Your little trick work for me.

[Arcanemagus]

Can anyone getting this error please post a file that reproduces it? This message is due to a bug in flake8 (which should be reported there), or in the attempts here to fix the terrible ranges flake8 gives for some messages.

@michaelhx That is only going to work if linter-flake8 is your only installed linter plugin, or Atom (randomly) decides to pick atom-linter from linter-flake8. The real issue is that we are getting a point specified as the source of a message that doesn't actually exist in the file.

[Arcanemagus]

I'll push out a bugfix release that shows the original message, which will help with comparing to the flake8 output you get on the CLI in a few minutes here.

[Arcanemagus]

v2.0.1 will show details of the original message in the developer tools so we can trace down where the bug is occurring.

If you see this please either post the file you are seeing this on and I will trace where the issue is, or follow these steps yourself:

• Run flake8 on the CLI yourself and see if the point of the message it gives is a valid point in the document, often issues happen around the end of the line, or with errors dealing with code that spans multiple lines (bracket/parenthesis checkers for example)
• If the positions from flake8 are invalid file a bug on the flake8 repo, possibly linking back to a relevant issue here.
• If the points from flake8 look valid, check if it is one of the messages we customize the range for, if so please file a new issue so we can track down the bug

[miketheman]

@Arcanemagus thanks for producing a debug build so swiftly!

I was able to reproduce the error and narrowed it down to this broken.py:

foo(

Basically, a broken syntax file.

Devtools shows:

Object {code: "E999", message: "SyntaxError: unexpected EOF while parsing", requestedPoint: Object}

flake8 on this file produces:

$ flake8 broken.py
broken.py:1:1: E902 TokenError: EOF in multi-line statement
broken.py:1:6: E999 SyntaxError: unexpected EOF while parsing

So it's clear that the file is broken, and flake8 is reporting it as such, but it's not being caught/reported correctly by the linter.

If you need more details, please let me know, I'm happy to help!

[Arcanemagus]

Thanks, this would be a bug in flake8 (reporting a column of 6 on a line with only 4 characters). I can't find a relevant issue from a quick search so I'll go ahead and report that over there.

Edit: Reported as https://gitlab.com/pycqa/flake8/issues/237.

[Arcanemagus]

As we are already fixing some of the ranges here I'm breaking a personal policy of mine and putting in a temporary workaround till this can be resolved in flake8 over in #262.

[wichert]

I think the problem here is specifically "unexpected EOF" errors, rather than all syntax errors. In that case flake8 reports a location at the point where it encountered the EOF, which is not a valid position in Atom. This error seems to be a regression in linter-flake8 2.0, previous versions did not report this error with the same flake8 version.

[Arcanemagus]

@wichert It's not a regression, but rather a fix to the detection of these invalid points. It should have been throwing this the entire time.

Are there other E999 errors that this workaround may cause issues for?

[Arcanemagus]

Pushed out v2.0.2 with the workaround.

[wichert]

@Arcanemagus Thanks for the fix!

I have to disagree with you on this not being a regression: from a users perspective the pre-2.0 releases worked fine, but immediately after upgrading to 2.0 I started getting what feels like a half dozen error messages on every new line of code I am typing, making the plugin entirely unusable. I've had to disable it everywhere so I could keep working.

[wichert]

The fix from #262 is incomplete: the same problem happens with other errors. For example E901:

$ echo if True: > x.py
$ flake8 x.py
x.py:1:10: E901 SyntaxError: unexpected EOF while parsing

x.py only has 9 characters (including the newline), not 10. I would not be surprised if this happens for other errors as well.

[Arcanemagus]

Just awesome, you would think a linter meant to check code validity would have tests for things like this...

[guillochon]

Error still happening for me with 2.0.2.

[Arcanemagus]

As an FYI I plan on implementing the same system outlined in AtomLinter/linter-eslint#735 (comment) here, so these messages will instead show as a "linter message", with the additional details being printed to the console.

[software-opal]

Would a suitable workaround be to implement a check if colStart == (lineText.length + 1); and if so, set the error to either the whole line or the last character. This could provide a quicker fix; and allow users who have flake8 pinned to use the linter.

[gpiffault]

It seems to have been fixed in flake8 3.1.0: https://gitlab.com/pycqa/flake8/issues/237

I upgraded to 3.2.0 and I'm not getting the error anymore.

[Arcanemagus]

Marking this as closed since this specific issue has been fixed in flake8.

[Arcanemagus]

v2.1.0 has been released which moves the error reporting to a Linter message.