Random error keeps popping up


When writing code, I’ll occasionally get the following error from /Applications/Atom.app/Contents/Resources/app/src/display-buffer.js:974:

Uncaught Error: No screen line exists when converting buffer row to screen row

This is obnoxious, as I am constantly having to dismiss the debug console. It happens even without any third-party plugins loaded.

The error seems to happen most frequently when I’m editing code at the end of a file, on the last line. But its happened when I create a few newlines (hit return multiple times) in the middle of the document.


Which version of the application are you on? I believe they fixed at least most of the reasons this came up in v0.137.0.


I am running 0.137.0, and it just happened again


Can you reproduce the error after completely closing Atom and starting it with atom --safe?


No, I wasn’t able to.

Which indicates that its probably a package. But the debug console doesn’t show any package specific failures


At this time you have to find the offending package the hard way by turning them on and off and reloading Atom each time. A tool to let you do an easier binary search for that process is in the works.


Alright, thank you. I’ve got a few ideas of when it happens, seems to be a conflict with one of the linters, specifically rubocop. I’ve been meaning to open a PR against it anyways, to switch it to the (much improved) json syntax, so perhaps I can look into it then.


Tracking things down exactly, @DavidLGoldberg suggested this tactic in the comments on my feature request for an atom bisect command:

I haven’t had a chance to try it yet, but it sounds promising.


I’ll have to try that. Will update with the result

On the plus side, I’ve only seen the error crop up a couple of times today.

Yesterday, when I opened the ticket, it happened 30 times, pretty much every time I added more carriage returns.

Unfortunately, the results not fruitful. I did see some errors, but nothing useful, just unable to find stylesheets with particular IDs. Everything else is just a yellow-level warning.

Thanks though!


Some clarification. This trick, has really nothing to do with the “audits” per se. That is ignore the “y-slow” like advice. What happens however is that the scripts’s errors should yield a better, more accurate, file source.

So for example, instead of “index.html:0” (which opens an empty file), you might get a real file with a real line number.

Also, this technique is really only when you can reliably reproduce the bug. A Binary search, git bisect like feature would probably have the same limitations of having to reproduce the bug first to I think :-\

Might want to try it again, in case you missed the console.log line?


So, Just a thought here. I’m sure this has been discussed in previous threads, somewhere, but… maybe @leedohm can weigh in on this or point me in the right direction / thread.

  1. Why can’t we have Atom try/catch all of the errors so they don’t pop up the inspector?
  2. Why are they even popping up the inspector in the first place? This is not normal behavior in let’s say the google chrome browser. As a user you only see the red errors when you open the inspector on a given page.

Just because we’re mostly all developers doesn’t mean we need to see the error. It might be relatively harmless and we just want to ignore it go on our merry way.

I’m sure this has been brought up before but haven’t seen a response about this…


I believe I’ve seen it discussed on Issues before (though I can’t find it right now because it was probably buried in the conversation about some other bug), but not really so much here on Discuss. I definitely understand where you’re coming from @DavidLGoldberg, but here’s the doomsday scenario I see:

  1. Person installs Atom
  2. Person happily installs a bunch of packages
  3. Person uses Atom
  4. One or more packages have bugs that throw errors, eventually destabilizing the editor and causing data loss

I wouldn’t want the hypothetical Person to think that Atom was chugging merrily along until it crashed and ate their data. That would be a perception nightmare. Could the error indicator be less obtrusive? Absolutely. But it can’t be completely ignorable or, even worse, missing altogether. Perhaps something like the Incompatibility Cop bug indicator that has a big, noticeable animation when a new error happens? Then you could ignore it … but you’d always see it.

Additionally, as a package author … I don’t want my package to be silently failing to do its job on other people’s computers. Then I’ll never get the feedback that I need to improve my packages.


Was anyone able to figure out what package was causing this? I’m gettng the same thing in 138 repeatedly. I literally cannot keep working because this keeps popping up every time I try to type something.

I agree that there should be a way to suppress the inspector… maybe only pop it up for the first error and if you close it don’t open it back up for the rest of the session?

Full stack trace on this one is:

Uncaught Error: No screen line exists when converting buffer row to screen row /Applications/Atom.app/Contents/Resources/app/src/display-buffer.js:974module.exports.DisplayBuffer.screenPositionForBufferPosition /Applications/Atom.app/Contents/Resources/app/src/display-buffer.js:974module.exports.Marker.getHeadScreenPosition /Applications/Atom.app/Contents/Resources/app/src/marker.js:211Marker /Applications/Atom.app/Contents/Resources/app/src/marker.js:45module.exports.DisplayBuffer.getMarker /Applications/Atom.app/Contents/Resources/app/src/display-buffer.js:1166module.exports.DisplayBuffer.markBufferRange /Applications/Atom.app/Contents/Resources/app/src/display-buffer.js:1198module.exports.TextEditor.markBufferRange /Applications/Atom.app/Contents/Resources/app/src/text-editor.js:1198module.exports.GitDiffView.markRange /Applications/Atom.app/Contents/Resources/app/node_modules/git-diff/lib/git-diff-view.js:182module.exports.GitDiffView.addDecorations /Applications/Atom.app/Contents/Resources/app/node_modules/git-diff/lib/git-diff-view.js:158module.exports.GitDiffView.updateDiffs /Applications/Atom.app/Contents/Resources/app/node_modules/git-diff/lib/git-diff-view.js:146(anonymous function) /Applications/Atom.app/Contents/Resources/app/node_modules/git-diff/lib/git-diff-view.js:3module.exports.Emitter.emit /Applications/Atom.app/Contents/Resources/app/node_modules/emissary/lib/emitter.js:118(anonymous function) /Applications/Atom.app/Contents/Resources/app/node_modules/text-buffer/lib/text-buffer.js:1069


In another topic, someone mentioned the atom-lint package. I can confirm that I get these errors occasionally (and I do use atom-lint), though mostly only on creating a new file and entering the first blank line. It may be that some linters employed by atom-lint run into the issue more often than others.


@leedohm, I agree but some other vantage points:

  1. The chrome browser has the possibility of causing some really bad misconceptions when errors happen too. Like oh I don’t know, the link didn’t actually sell all of my stock shares in time :wink: Or instead of deleting some message in draft it sends it…

  2. We rely on the robustness of the site in the above cases. So in our case it would be the package (probably more confusing in our case with Atom I know, just saying).

  3. It’d be interesting if we could divide the intents of the functions of a given package’s execution into different kind of tasks. Some of which error more egregiously than others (probably a bloated / bad idea)


Also, looking at SublimeText as an example of an editor with packages, many packages in ST may also cause errors. But ST2 doesn’t pop open its console for every single one. It doesn’t pop it open at all, unless its been configured to.

The only time an error is presented to the user is if it is a fatal, in which case you get a dialog box.


I guess people keep missing this part of what I said.


Fair enough. Maybe put a red x with a number next to it in the status bar, that indicates the error status?


And when you click it the console opens.


I see this error fairly often still in 139. its not happened today though. the ticket is still open

its something to do with an invalid marker. so its not something that would damage the document contents itself and in this case I think that core (display-buffer.js) could post an error (not throw it) and remove the invalid marker.

if it is something that might cause data loss then it should throw because its serious.