Use rangeFromLineNumber() in parse() about atom-linter HOT 9 CLOSED

We actually cannot do this because we do not accept textEditor in parse, we can change that if we really want to do this. Thoughts?

from atom-linter.

Personally I think the benefit of the much better ranges returned to the user is worth the addition of passing in a TextEditor to the parse method, and I can't think of any cases where that would pose a major problem.

Almost all of the maintained linters long ago abandoned the parse() method, so this will mainly be an issue for the linters that need attention anyway.

from atom-linter.

So you would need to pass TextEditor, data, regex and options/flags? Mmm is there a way to reduce the number of things passed?

Maybe this library could generate a parser object, its constructor would take the regex and it's flags. This object can be stored by the linter. When you call the parse function of this object, you pass the TextEditor and the data generated by the linter, and that returns a valid Message.

Would there be a need to pass the filepath? You can get that from the TextEditor anyway

from atom-linter.

I just realized we can work around the need to pass in a TextEditor by using the approach taken here.

Essentially all open TextEditor's are searched for (the first) one matching the path from the message, if one can be found it is used to enhance the range returned with a "word range", otherwise the range can fall back to the current version where we just generate a fake one character range, and leave it to a subsequent lint when that file is open to expand it.

If we also move to using a JavaScript RegEx object instead of the XRegExp library, we can just have a raw regex passed in, which would allow us to cut out the flags part of the options. Combining the two allows the options parameter to be removed entirely.

I'm still not sure whether this function should be implemented at all, but the above plan would at least get us better ranges when possible, without requiring an additional parameter.

from atom-linter.

If the needs for flags is removed then it would be preferred to pass the TextEditor object itself, and not just it's path.

But if you are to implement this please consider bundling #166 in the mix to reduce the needed massaging currently required for parse

PS: We could make a list of linters currently using parse (I would be glad to submit PRs to them to upgrade to this new syntax with the proposed enhancements)

from atom-linter.

If the needs for flags is removed then it would be preferred to pass the TextEditor object itself, and not just it's path.

I meant the path would also be omitted, since it should be being parsed from the messages. Thinking about it a bit more though, it would have to be an optional argument for the linters that don't give the path in their output.

If we search for the TextEditor instead of relying on it being passed in then parse could be used for project level providers... not that it should 😛.

consider bundling #166 in the mix

Updating to v2 messages is a breaking change, if the parameters passed in here end up being changed then that will definitely be included since both are breaking changes.

from atom-linter.

Cool with me! Just a question about generateRange how would you provide a colEnd like the one that parse accepts?

Also how would you use a simple RegEx to provide all the information needed in parse? I didn't get that part

from atom-linter.

Just a question about generateRange how would you provide a colEnd like the one that parse accepts?

If you have a colEnd, then you don't need to call generateRange at all as you have an entire range already 😉.

Also how would you use a simple RegEx to provide all the information needed in parse? I didn't get that part

XRegExp is just a library that allows "perl like" regex, the major difference being that in pure JS regex you can only have a capturing group /(stuff)/, which with other libraries you can name a capturing group /(<name>:stuff)/. It's just a convenience tool... unfortunately I think we would need to keep it in here since the regex passed in is going to have different orders of where things are in the results, meaning we can't just use the same index into the result array for say "line".

from atom-linter.

Closing as the parse method will be being removed in a future release.

from atom-linter.