Upgrade support for linter API to v2

[mallman]

The atom linter package recently released their 2.0 API, which breaks atom-sbt linter support. Please upgrade the atom-sbt linter support to the 2.0 API. The new API is documented here

http://steelbrain.me/linter/

and includes a migration guide.

[inkytonik]

Yes, I will take a look as soon as I can. It's unclear to me right now whether every linter-using package needs to upgrade to the new linter API or whether 1.0 and 2.0 can co-exist...

[laughedelic]

which breaks atom-sbt linter support

What's broken? I haven't noticed any problems, except of not working keymaps.

[mallman]

which breaks atom-sbt linter support

What's broken? I haven't noticed any problems, except of not working keymaps.

When I run compile, I don't get a list of errors in the linter UI, even if I open a file with an error. It just says "0 0 0" at the bottom. Sometimes it does report errors, but most of the time it does not. Also, I don't see a way to show all project errors, but maybe that's a problem with the linter UI itself.

As you mentioned, the alt-shift-. key combo does not work.

[inkytonik]

As of a22c61b the package has moved to Linter V2. It seems to be working well, but if you have a chance, please try the latest master and report any problems you see.

[laughedelic]

Could you also integrate the Busy-Signal API to show progress while SBT is compiling?

[inkytonik]

Yep, that's a good point. Should be easy. Will take a look.

[inkytonik]

As of bd69a11 there is support for Busy Signal, both for sbt startup and each sbt command issued. Please let me know how it works for you.

[laughedelic]

It doesn't seem to ever stop. Since I start sbt it starts spinning and doesn't stop when sbt has loaded or when compilation has finished.

[inkytonik]

Are you using a continuous command (e.g., "~compile")? I haven't yet tried to support only showing a busy signal when that sort of command is actually doing something, as opposed to when it is waiting for a file to change.

[laughedelic]

No, it's spinning all the time. Irrespectively of any commands I run (even non-continuous).

[inkytonik]

Hmm, ok. Will look into it, but it didn't happen for me. Can you try different projects in case it's something project specific?

[inkytonik]

It's keyed off the prompt pattern, so maybe you have a more general (I.e., matching more often) pattern?

[laughedelic]

Yes, I use a custom prompt, so I guess, it just doesn't match.. It looks something like this:

[info] Loading global plugins from /Users/laughedelic/.sbt/0.13/plugins
[info] Loading project definition from /Users/laughedelic/dev/ohnosequences/loquat/project
[info] Updating {file:/Users/laughedelic/dev/ohnosequences/loquat/project/}loquat-build...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Set current project to loquat (in build file:/Users/laughedelic/dev/ohnosequences/loquat/)
[SBT] project loquat branch master » 

And when it doesn't run update, it's just

[info] Loading global plugins from /Users/laughedelic/.sbt/0.13/plugins
[info] Loading project definition from /Users/laughedelic/dev/ohnosequences/loquat/project
[info] Set current project to loquat (in build file:/Users/laughedelic/dev/ohnosequences/loquat/)
[SBT] project loquat branch master » 

So probably matching [info] Set current project to would work better?

[inkytonik]

I've tried a bunch of solutions previously for this sort of problem. It turns out everything works much more cleanly if I can detect when the prompt is shown. Not just the busy signal but things like detecting which commands are typed interactively.

It's not enough in my experience to rely on what sbt normally prints, since various settings can change that. E.g., if info messages are turned off the "Set current project to ..." message doesn't appear.

If you have a non-standard prompt, you will need to set the new Prompt Pattern setting to match it. Hopefully then everything will work properly.

[inkytonik]

Supported in version 0.9.0 which is now published.

[laughedelic]

Hey! Thanks a lot for releasing it 👍
To be honest, the prompt pattern setting is quite inconvenient, but if setup correctly, works fine. And the busy-indicator is super useful (especially with long compiles).

[inkytonik]

Thanks for the feedback. I agree that having the prompt pattern setting is less than ideal. I have experimented with a version that asks sbt what the prompt is, but this was quite unreliable too, since to reliably get it we need to know what the prompt is. There are all sorts of race conditions if we just send things and read the responses. The prompt pattern is tedious but should only have to be done once and is reliable.

[laughedelic]

I still think that this setting is not reliable (see #20). I wonder what are the problems with using the finalRE pattern instead of the prompt? (except capturing the entered command name)

[inkytonik]

I think it is possible for the final success message to be suppressed (unusual I know). Also, capturing the entered commands is important to get the history and "run last command" features to work, so I need to do it anyway.