linting on fly about linter-gcc HOT 19 CLOSED

Linting on-the-fly has been deliberately disabled since linting is achieved by compilation, which can be both time and cpu-intensive. Compiling a source file with every keystroke is therefore, not feasible.

from linter-gcc.

Understand, it is possible to start a lint process after finishing a line with Enter/Return, maybe as an option to handle with small resources?

from linter-gcc.

Unfortunately, the linter api (which linter-gcc relies on) doesn't give you this level of flexibility. It only allows you to turn linting on-the-fly on and off. Turning it on means the source file is recompiled with every keystroke, which is not feasible.

from linter-gcc.

Ok, how can I turn the option on?

Am 31.01.2016 um 15:52 schrieb Husam Hebaishi [email protected]:

Unfortunately, the linter api (which linter-gcc relies on) doesn't give you this level of flexibility. It only allows you to turn linting on-the-fly on and off. Turning it on means the source file is recompiled with every keystroke, which is not feasible.

—
Reply to this email directly or view it on GitHub #21 (comment).

from linter-gcc.

The linter doesn't work when you turn on linting on-the-fly. You simply get no errors even when are errors in your source file. If you still wish to turn the option on, you will need to fork linter-gcc and turn make the change yourself.

from linter-gcc.

I found the option lintOnFly, is this the only change i need to make?

Thank you for your help

sstaub

Am 31.01.2016 um 17:57 schrieb Husam Hebaishi [email protected]:

The linter doesn't work when you turn on linting on-the-fly. You simply get no errors even when are errors in your source file. If you still wish to turn the option on, you will need to fork linter-gcc and turn make the change yourself.

—
Reply to this email directly or view it on GitHub #21 (comment).

from linter-gcc.

/cc @steelbrain

from linter-gcc.

@hebaishi We actually have several types of linter providers. There are traditional ones that are triggered on keypress or save, and there are indie ones that are completely managed by the provider. The provider can set or remove messages at any time.

See Linter-Indie API in Linter docs

from linter-gcc.

Hmm... this is very interesting. Ok I will have a play and try to implement a lint on-the-fly feature that works when the user presses Enter.

from linter-gcc.

Hello @sstaub. I am working on an update to linter-gcc that will have linting on save switched on by default, but allow the user to turn on linting on-the-fly as well.

from linter-gcc.

Thank you very much, that will us help. I am working with plattformIO and this is missing killer feature. Because of working with embedded systems like arduino and mbed, resources are not such a big problem.

sstaub

Am 01.02.2016 um 17:51 schrieb Husam Hebaishi [email protected]:

Hello @sstaub. I am working on an update to linter-gcc that will have linting on save switched on by default, but allow the user to turn on linting on-the-fly as well.

—
Reply to this email directly or view it on GitHub.

from linter-gcc.

I have got it working pretty well now. The only thing to note is that it saves the file after every change. The automatic saving only happens if linting on-the-fly is enabled, but getting it to work another way would involve either creating a temporary file somewhere, and making sure that the include paths work properly, or somehow trying to pipe to g++ from stdin, which would be messy. What do you think?

from linter-gcc.

@hebaishi We also have a tempFile helper in atom-linter

from linter-gcc.

@steelbrain you guys really have thought of everything! All sounds brilliant!

from linter-gcc.

Linting on-the-fly is on the way! Writing the tests at the moment, update will likely come tomorrow.

from linter-gcc.

@steelbrain I'm having an issue with linting on-the-fly. The linter works as expected - when a C/C++ file is opened and edited, the error messages are updated correctly. I have added a cleanup function that removes error messages from closed TextEditors, and this seems to be the issue. Saving the file and closing it works as expected - the messages of the closed file are removed. But if you open a file, edit it, and close it without saving, you get this error in the console:

Uncaught (in promise) Error: Given editor is not really an editor
    at MessageRegistry.set (/home/husam/.atom/packages/linter/lib/message-registry.js:41:15)
    at /home/husam/.atom/packages/linter/lib/linter.coffee:37:17
    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/husam/.atom/packages/linter/lib/linter-registry.js:66:26

I have pushed my changes to a new branch called 'test'. Do you think you could help me with this?

Edit: Just wanted to add that when this happens, the normal prompt asking if you want to save the file doesn't appear.

from linter-gcc.

@steelbrain I think I have idenfied the problem. The issue is that I had atom's auto-save switched on. It somehow interacts with linter and causes this problem when a destroyed TextEditor is auto-saved. When I switch it off, everything works perfectly

from linter-gcc.

Ok. Package updated with linting on-the-fly. Please update to start using it!

from linter-gcc.

Cool, thank you very much, this makes our work much easier.
A restart of atom is necessary.

sstaub

Am 08.02.2016 um 13:29 schrieb Husam Hebaishi [email protected]:

Ok. Package updated with linting on-the-fly. Please update to start using it!

—
Reply to this email directly or view it on GitHub #21 (comment).

from linter-gcc.