Integrate with existing tools about vale

[jdkato]

I've implemented support input for stdin:

# Will be treated as plain text
$ vale 'This is some text to lint'
...
# Will be treated as Markdown
$ vale --ext='.md' 'This is some text to lint'
...
# Will be treated as plain text
$ echo 'this is more text' | vale
...

should all work now. I also have this working on a branch of the Sublime Text plugin (https://github.com/ValeLint/SubVale/blob/feat/buf/Vale.py#L53).

[chew-z]

There was a small, unrelated bug in ale which just had been fixed.

So now VIM+ale+vale is beautifully working for me with very minimal plugin in .../ale/ale_linters/markdown/vale.vim:

call ale#linter#Define('markdown', {
\   'name': 'vale',
\   'executable': 'vale',
\   'command': "vale --output=line %t",
\   'callback': 'ale#handlers#unix#HandleAsWarning',
\})

btw: what is option --ext='.md' good for?

[w0rp]

@chew-z With %t in ALE, the temporary filename created will use the same basename as a file you're editing, so it should be able to pick up the file extension from there.

[TimKam]

Are you already working on an Atom plugin? If not, I could give it a try.

[jdkato]

I haven't started working on it, so the help would be much appreciated.

Thanks!

EDIT: Also, let me know if there's anything I can do to help -- I know Vale's documentation is poor at the moment.

[TimKam]

Thanks. I plan to have a first version ready at the weekend.
I was wondering, though, if Vale can process text that is provided directly as an argument on the command line.
For example, vale --text="Lint this text" - or similar. This would make linting text on the fly more practicable.

[jdkato]

No, this isn't currently supported. I'm not against adding this functionality, but I haven't decided on the best way to handle it yet.

Since Vale tries to be smart about syntax (e.g., ignoring code blocks), it'd either have to treat all text from --text as plain text or you'd need to specify the format (--text="Lint this text" --format="...", perhaps) since there's no file extension.

[TimKam]

Ok. Then it's linting on save for now, but I'm happy to make it on-the-fly linting once you implement this.
The first version of the Atom plugin is available at https://atom.io/packages/atomic-vale, respectively https://github.com/TimKam/atomic-vale.
I can transfer ownership, if you prefer.

[jdkato]

Thanks—it looks great! I'll let you know once I've implemented support for on-the-fly linting (it should be reasonably soon).

As far as ownership goes, I'm fine with you keeping it. It's up to you, though.

[TimKam]

Ok, then I'll keep ownership for now.

[chew-z]

I think vale should give other exit code then zero when there are some errors or warnings.

vale 'This is some some text to lint'
✔ 0 errors, 0 warnings and 0 suggestions in 1 file. 

vale 'This is very very text to lint'

 stdin.txt
 1:9   warning  Consider removing 'very'  vale.Editorializing
 1:14  warning  Consider removing 'very'  vale.Editorializing

✖ 0 errors, 2 warnings and 0 suggestions in 1 file.

Some other tools relay on non-zero (1) exit code to process the output further.

[jdkato]

@chew-z: Vale should exit with (1) on errors already (for example, I'm using Vale to lint its own documentation on Travis CI and the build will fail on errors). I think this is reasonable default behavior as you'll likely want to ignore many warnings and you can always change the rule's level if not:

[*]
vale.Editorializing = error

That said, I'm open to making this more configurable. Would you want a setting to control which levels result in a non-zero exit code?

[chew-z]

Yes, I think it would be useful to have more control over non-zero exit.

What I have been trying to do in a very lazy way was integrating vale with vim through ale plugin. I have simply copied plugin for proselint which comes to calling external command on a copy of current file. This should be simple enough but I had no luck so far.

Called from internal shell vale returns nice warrnings just like proselint

:!vale --ext='.md' "%"

but proselint is also returning exit 1 and this is what triggers ale into action, I think. This is common convention in vim that it is passing quietly when exit code is zero.

I will digg into that more tomorrow.

[jdkato]

After glancing at one of the implementations for proselint, I noticed that its callback (ale#handlers#unix#HandleAsWarning) expects Unix-style output. You may want to try passing the --output=line option to Vale, which will give the expected format:

$ vale --output=line /test/double.md
/test/double.md:2:13:vale.Repetition:'be' is repeated!

[jdkato]

Vale needs to know the format of a file so it can properly lint it (e.g., skip code blocks, etc.). This is normally done by inspecting the file extension, but there's no extension when input is given via stdin. So, you can optionally specify one with --ext (if omitted, Vale will treat input as .txt and apply no special logic).

[chew-z]

So my pull request has been accepted and glue for vale is now part of ale.

So it could be said that now vale is integrated also with VIM.

[jdkato]

Thanks! I've updated the README.

[swsnr]

FYI, I wrote and published a VSCode extension. I'm sorry; I didn't realise you were already working on one, and I'm happy to deprecate my extension when the official one is ready.

[jdkato]

@lunaryorn: Oh, that's okay! Mine is in pretty rough shape anyway, so I think I'll just defer to your work.

[swsnr]

@jdkato Thanks 😊

[ChrisChinchilla]

@jdkato Can we reopen this, or track some of the other integration points elsewhere? I am working on some browser plugin ideas…

[ChrisChinchilla]

One really useful step that I'm a bit stuck on is figuring out how to run vale on a remote host. I'm not too familiar with go to know the best and most cost-effective way of doing this though.

[jdkato]

@ChrisChinchilla: Sure, I've created a new issue (#97) where we can discuss browser addons/plugins.