steelbrain / atom-linter Goto Github PK

Currently we have colEnd - baseReduction:

at line 79

colEnd = match.colEnd - options.baseReduction if match.colEnd

But consider the follow:

Assume we have a token f at line 1, column 2 cause an error. As a linter would reoport error like:

line 1 started at column 2 ended ad column 2 token f makes an error....

So should we say ended ad column 2 or ended ad column 3? IMHO, we should say ended ad column 2.

For a linter tool the column range is inclusive (like [x..y]). But for atom-linter used the range is left inclusive right exclusive (like [x..y)).

So I think:

• we should not do colEnd - baseReduction for colEnd case.
• or we should have one more option like colEndReduction.

While upgrade linter-jshint to the latest version 1.1.2, i found it doesn't work any more on windows. See following snapshot:

But the issue has nothing to do with OSX. I am running my atom on windows.

After some debug work, the issue is caused by lib/helpers.coffee line 18:

return @_exec(process.execPath, args, options, true)

The process.execPath returns C:\Users\howard\AppData\Local\atom\app-1.0.2\atom.exe which is absolutely incorrect.

We should be checking the exit code of applications, so if they exit with a 1 and we aren't expecting output on stderr something gets thrown back to the caller to notify that something is wrong.

Of course with how badly most linters are written there probably needs to be a flag to ignore that as well...

While editing tex files, I would see the error:

Error: Process execution timed out
    at /Users/caj/.atom/packages/linter-javac/node_modules/atom-linter/lib/helpers.js:79:18

I tried uninstalling that, now I get the same error from linter-clang, still while I am in a project with no java, c or c++ files!

I'm not sure what's going on. I think it happens when I run latex, which causes a number of files to quickly appear and then be deleted.

I'm currently getting

Error: Column start (11) greater than line length(8)
at Object.module.exports.Helpers.rangeFromLineNumber
lib/Helpers.coffee:73:17

while running [email protected]

related to pull request #53 ?

A new stream type both, which will help linters collect both streams if they want to.

It'd be very handy to be able to define Regex Flags has an option in the parse method.

Some linter-s have dependencies included, others seem to find them ok (I presume via $PATH), and others force you to explicitly specify the full path to the binary in the config, and break without that.

I'm not sure if this is the right place for this issue, but is there some way there could be more consistency between all of the linter-s, making them more robust?

Atom now has a built in function to determine whether something is a TextEditor, we should switch to using that instead of checking for function names since multiple objects can have a function defined.

An example implementation is in atom/autocomplete-plus#622.

I though this was fixed, maybe a regression.

Use Child_Process.fork in it, instead of spawn. See steelbrain/linter#743 (comment)

40d9f0e broke linter-js-standard. See ricardofbarros/linter-js-standard#30

@steelbrain
I fixed the problem in AtomLinter/linter-jshint#151. You need to have an options object and pass it into bufferedNodeProcess :

    options =
      env:
        ATOM_SHELL_INTERNAL_RUN_AS_NODE: '1'

   spawnedProcess = new BufferedNodeProcess({command, args, options, stdout, stderr, exit})

I can create a PR for the atom-linter code if you would like.

Occasionally it would still be desirable to highlight the entire rest of the line, even if a word can be determined (see AtomLinter/linter-pyflakes#38 (comment)).

Add a flag to rangeFromLineNumber making it behave as it did in the previous version.

Then decorate the same range across multiple editors

Not yet confirmed, Source: AtomLinter/linter-javac#23 (comment)
Kelper indicated he wanted to work on this, not quite sure.
/cc @k2b6s9j

I can't unsee it.

At the scale Atom renders it, it looks like an angry face.

Reminds me of Cartman's angry face

To be filed under enhancement.

p.s. thank you for your linter packages, they're awesome.

Just like the title says

I installed linter-pep8 to work on some python files, and didn't realize I had to install pep8 separately. When this happens atom-linter pops up a red message with this text:

Error: spawn pep8 ENOENT
    at exports._errnoException (util.js:837:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:178:32)
    at onErrorNT (internal/child_process.js:344:16)
    at doNTCallback2 (node.js:441:9)
    at process._tickCallback (node.js:355:17)

Can this message be replaced with a clearer error message? Something like, 'linter binary for "linter-xxx" plug-in not found.'

Just like the title says

Steps to repro:

Open a file
Open the settings
Close Atom
Open Atom

In the lower right corner the following UI element shows up, I'm not sure what it is. It only happens when Atom restores the previous session and was focussed on the settings.

Disabling Linter and/or tabbing away from the settings once and then back fixes it.

After updating the atom-linter dependency from 4.7.0 to 5.0.2, I had a linter package break with the following stack trace:

Error: Process exited with non-zero code: 2
    at ChildProcess.<anonymous> (node_modules/atom-linter/node_modules/sb-exec/lib/index.js:46:22)
    at emitTwo (events.js:87:13)
    at ChildProcess.emit (events.js:172:7)
    at maybeClose (internal/child_process.js:818:16)
    at Socket.<anonymous> (internal/child_process.js:319:11)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at Pipe._onclose (net.js:469:12)

I checked the release notes for the sb-exec breaking change and modified my exec accordingly to:

return helpers.exec(executable, args, {cwd: path.dirname(file), allowEmptyStderr: true}).then(output => {

but the same stack trace resulted.

When processing text on the stderr stream ({stream: 'stderr'} or {stream: 'both'}), we should still handle EACCES errors.

Hello, maybe this a non-issue but I really couldn't find anything on the settings.

Right now it's only showing the error/warning message on the error panel when only I have my cursor at the line.

Is this the normal behaviour? or is there some setting where I can set to see all the error/warning message that I currently I have on the file?

TypeError: path must be a string
    at TypeError (native)
    at Object.fs.access (fs.js:192:11)
    at /home/steel/.atom/packages/flow-ide/node_modules/atom-linter/lib/helpers.js:244:10
    at findCachedAsync (/home/steel/.atom/packages/flow-ide/node_modules/atom-linter/lib/helpers.js:243:18)
    at Object.<anonymous> (/home/steel/.atom/packages/flow-ide/lib/index.js:54:36)
    at [object Generator].next (native)
    at step (/home/steel/.atom/packages/flow-ide/lib/index.js:3:273)
    at /home/steel/.atom/packages/flow-ide/lib/index.js:3:443
    at Object.lint (/home/steel/.atom/packages/flow-ide/lib/index.js:3:99)
    at linters.forEach.promises.push.Promise.then._this2.emitter.emit.linter (/home/steel/.atom/packages/linter/lib/linter-registry.js:67:26)
    at /home/steel/.atom/packages/linter/lib/linter-registry.js:66:23
    at Set.forEach (native)
    at LinterRegistry.lint (/home/steel/.atom/packages/linter/lib/linter-registry.js:63:18)
    at /home/steel/.atom/packages/linter/lib/linter.coffee:110:16
    at Function.module.exports.Emitter.simpleDispatch (/usr/share/atom/resources/app.asar/node_modules/event-kit/lib/emitter.js:25:14)
    at Emitter.module.exports.Emitter.emit (/usr/share/atom/resources/app.asar/node_modules/event-kit/lib/emitter.js:125:28)
    at /home/steel/.atom/packages/linter/lib/editor-linter.js:20:20
    at Function.module.exports.Emitter.simpleDispatch (/usr/share/atom/resources/app.asar/node_modules/event-kit/lib/emitter.js:25:14)
    at Emitter.module.exports.Emitter.emit (/usr/share/atom/resources/app.asar/node_modules/event-kit/lib/emitter.js:125:28)
    at TextBuffer.module.exports.TextBuffer.saveAs (/usr/share/atom/resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1067:27)
    at TextBuffer.module.exports.TextBuffer.save (/usr/share/atom/resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1037:19)
    at TextEditor.module.exports.TextEditor.save (/usr/share/atom/resources/app.asar/src/text-editor.js:602:26)
    at Pane.module.exports.Pane.saveItem (/usr/share/atom/resources/app.asar/src/pane.js:534:18)
    at Pane.module.exports.Pane.saveActiveItem (/usr/share/atom/resources/app.asar/src/pane.js:517:19)
    at Workspace.module.exports.Workspace.saveActivePaneItem (/usr/share/atom/resources/app.asar/src/workspace.js:648:35)
    at atom-workspace.commandRegistry.add.core:save (/usr/share/atom/resources/app.asar/src/register-default-commands.js:173:32)
    at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/usr/share/atom/resources/app.asar/src/command-registry.js:260:29)
    at /usr/share/atom/resources/app.asar/src/command-registry.js:3:61
    at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/usr/share/atom/resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:536:16)
    at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/usr/share/atom/resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:359:22)
    at WindowEventHandler.module.exports.WindowEventHandler.handleDocumentKeydown (/usr/share/atom/resources/app.asar/src/window-event-handler.js:97:36)
    at HTMLDocument.<anonymous> (/usr/share/atom/resources/app.asar/src/window-event-handler.js:3:61)

Seems like we're caching even the null result of atom-linter::findCachedAsync, we shouldn't cache it when it's null

I am pretty sure, after updating one of the linters or the main linter package today, this happened:

When disabling atom-linter, the problem is gone.

I am using the pen-paper-coffee syntax theme (i am the maintainer), which adds a 'margin-rightto the.gutter` for better readability. Setting other themes, the linter custom element looks ok.

What can we do about it?

Remove the exports or findFile() and findFileAsync() kept in for backwards compatibility.

This was meant for the v4 API, but got missed.

rangeFromLineNumber should actually return a Range object, instead of a "Range compatible array".

See AtomLinter/linter-eslint#429 for details, we need to verify the changes in #102 still work for Atom <1.4.0.

When using atom-linter to execute a linter (e.g. eslint, rubocop, flake8) on the file currently being edited, as in the way most of the linters are doing (return helpers.exec(atom.config.get('linterExecutablePath'), args, {stream: 'stdout'}).then(output => {), is there any way to catch errors thrown by the linter?

I skimmed index.js and nothing jumped out at me.

we should tell the user that the target is not executable or it's a directory.

Currently being triggered by the following steps in linter-eslint, but stopping it here will fix anywhere else that this is causing crashes on:

1. Try to run linter-eslint with a module missing ("parser babel-eslint requested but not installed
2. Get a response from the linter of:

{
  "message": "Cannot find module 'babel-eslint'",
  "line": 0,
  "column": 0,
  "severity": 2
}

3. Helpers.rangeFromLineNumber(textEditor, line - 1) is then called, meaning rangeFromLineNumber is being called with a line of -1.

So, tl;dr: Verify that lineNumber and colStart are within the valid range for a line before attempting to call Atom functions.

I want to give a command line argument --find-config which will find the given document from the current directory.

How do I change the directory where atom-linter's exec function is run

Just copy PATH and some useful ENVs like USER and USER_HOME and stuff.
Fixes AtomLinter/linter-jshint#145

Use npm version <bump type> for releases so that a git tag is created.

https://docs.npmjs.com/cli/version

It was added by @k2b6s9j but I don't really see the point in it's existence, I've ported quite a few CLI linters and didn't need it.

Is this actually this package, or something internal to Atom?

We should use rangeFromLineNumber() in parse() to generate the range, that way we don't end up with one character "ranges" if the linter doesn't specify an end column.

Hello,

I'm investigating why I have this error when I try to perform a child_process.exec with linters activated, here:
AtomLinter/linter-jshint#191

I made a diff of process.env in Atom, before and after linters activation, and this one seems very suspicious:

So the OS is deleted somewhere. I just fast-explored the commits and maybe this one is related because there is some env management modification:
42b68ca

What do you think? Is that normal?

Thanks!

I am trying to make a linter using atom-linter like the linter-pep8 - https://atom.io/packages/linter-pep8

The linter is for coala - https://github.com/coala-analyzer/coala
You can find the code here - https://github.com/coala-analyzer/coala-atom

I get the error mentioned below - which states the atom-linter library is not found. It works fine in linter-pep8 because that plugin works for me - but the coala-atom plugin does not.

Atom Version: 1.0.2
System: "Arch Linux"
Thrown From: coala-atom package, v0.0.1

Stack Trace

Failed to activate the coala-atom package

At Cannot find module 'atom-linter'

Error: Cannot find module 'atom-linter'
    at Module._resolveFilename (module.js:328:15)
    at Function.Module._resolveFilename (/usr/share/atom/resources/app.asar/src/module-cache.js:383:52)
    at Function.Module._load (module.js:270:25)
    at Module.require (module.js:357:17)
    at require (module.js:376:17)
    at Object.module.exports.provideLinter (/mnt/data/software/arch/jhbuild/other/coala-atom/lib/main.coffee:14:17)
    at Package.module.exports.Package.activateServices (/usr/share/atom/resources/app.asar/src/package.js:369:69)
    at Package.module.exports.Package.activateNow (/usr/share/atom/resources/app.asar/src/package.js:243:16)
    at /usr/share/atom/resources/app.asar/src/package.js:221:30
    at Package.module.exports.Package.measure (/usr/share/atom/resources/app.asar/src/package.js:165:15)

Commands

Config

{
  "core": {
    "themes": [
      "atom-light-ui",
      "atom-light-syntax"
    ],
    "autoHideMenuBar": true,
    "disabledPackages": [
      "linter-pylint",
      "linter-pylint",
      "atom-zeal"
    ]
  },
  "coala-atom": {}
}

Installed Packages

# User
coala-atom, v0.0.1
linter, v1.3.2
linter-pep8, v1.0.1

# Dev
No dev packages

Several plugins are having issues importing this using this form:

import helper from 'atom-linter';

While this works just fine:

import * as helper from 'atom-linter';

Either of them should work, but the first one seems to be broken since v3.4.0, leading to helper being undefined.

It would be nice if there was an option that allowed limiting find() searches to a certain level. See AtomLinter/linter-jshint#181 for an example use case.

It'd be very handy to have Trace captures pulled out and handled correctly. Here's an example that I'm working with for linter-gradle.

As pointed out by @joefitzgerald there is a package avialable that provides a unified environment on OS X that matches what you would expect from process.env on other platforms. Since most packages use this to run their linters we should probably implement this here to simplify things for the OS X users.

Thoughts?

Currently, spawned processes will tail on and eat up CPU usage (in some cases, e.g linter-phpcs). Results should be pretty much instant anyway, so I thought opening up the option to limit execution time to linters would prevent this problem.

It didn't make sense to open this on the linter-phpcs as this could happen to any linter, should the process not exit correctly.

Just like the title says

In AtomLinter/linter-scalac#46 linter-scalac is having issues on it's AppVeyor CI build due to scalac not being found: https://ci.appveyor.com/project/andystanton/linter-scalac-3ymif/build/32

From the build history it looks like this is a new issue.

The URLs all still point to when this repo was part of AtomLinter.

In rangeFromLineNumber currently when an invalid line is encountered a range pointing to the very first character in the file is returned. Instead we should just set the line to the first line of the file and let the rest of the code run, giving us a range that encompases the entire first line.