Something went wrong internally.

[despairblue]

This linter also lints markdown files containing fenced code block with javascript.

This call returns nothing for markdown files.

This thus leads to a lot of warnings :smiley:

Something went wrong internally.
No sweat, just re-open this file and this annoying warning shouldn't appear anymore

[ricardofbarros]

If you open a markdown file you are not supposed to get to that line, there is a grammarScope and the only files that call the lint function are ['source.js', 'source.js.jsx', 'source.js.jquery'].

But regarding your issue, yes I'm aware it leads to a lot of warnings on some situations.

One of those situation is when I still have a file tab open but I have already deleted the file thus sending that annoying warning message.

[despairblue]

A fenced code block containing javascript in a markdown file has that grammarScope:

Scopes at Cursor

• source.gfm
• markup.code.js.gfm
• source.js
• support.constant.dom.js

[ricardofbarros]

Hmm okay I understand,

Well we could explicitly ignore that file grammar with textEditor.getGrammar() at that line.

[ricardofbarros]

Okay I have been sniffing around this issue and I got this conclusion.

I have to parse the stdin of .md files that call the lint() function then I need to strip all its content less the js fence code blocks, extract the js code, glue it together and lint it.

But nevertheless, this would be a cool feature for linter-js-standard, but of course the user should have a option to make linter ignore .md files or lint them.

@despairblue What are your thoughts on this?

[despairblue]

If you're willing to implement this, that certainly would be a cool feature and I don't think a lot of linters do that. :sunglasses:

Though I'm not sure about the gluing together part. Sometimes the different code blocks have nothing to do with each other :worried:

[ricardofbarros]

Yeah you're right, most of times actually, now that I think of it.

So It would need to call the standard bin for each part

[stephenkubovic]

This seems to be affecting newly saved .js files as well. That same line returns undefined after saving a new file.

[blakeembrey]

Could this be disabled for now? I find I need to disable the plugin as I can't see half the screen after not too long typing.

[ricardofbarros]

Correct me if I'm wrong, but this is only happening in the following situations:

• markdown files with js fenced code;

• files that were renamed and the panes are still open.

  I managed to fix the problem with the markdown files but not with the renamed files.

So I won't close this issue, but this is dependent of the following issues: atom/tree-view#433 and atom/atom#8432

The latest release 2.5.0 fixed the markdown issue.

@despairblue I didn't implement the feature to lint fenced code because in the end it doesn't make sense to lint "explanatory" code.

[blakeembrey]

@ricardofbarros I'm not so sure about not linting Markdown text, I like the idea as I find I forget to update it sometimes (and it should definitely match the format of the library). As for the filename issue, can't you always use stdin?

[ricardofbarros]

@blakeembrey Yes it's a good idea but the linter will often output errors from your fenced code, such as: - "unused var"

• etc.

And this can be annoying.

I could always add a workaround for markdown files to ignore some particular recurring errors, but is this the right approach?

I use the filename to cache standard/semistandard settings harvested from the file's nearest package.json and then I pass those args to the cli. (parser, global, etc)

[despairblue]

@ricardofbarros not linting markdown files is fine for me. But if the code already exists why not make an option to disable it? If the code does not already exist, I don't see why it couldn't be included if someone wants to write it (it has to be disableable, is that a word?).

I don't like the idea of disabling parts of standard. The whole point of standard is that we shouldn't have to think about it.