Closed TeroFrondelius closed 7 years ago
@TeroFrondelius Can you ping me again when this is ready to be reviewed? I don't have much time these days, so would prefer to look at a final version.
@davidanthoff sure I will ping you again. Now there is only a fundamental question: should I keep as it is, or should I change that all messages are sent as one json. Now: {file: 'none', code: 'E321' ...}
, other option: [{file: 'none', code: 'E321' ...}, {file: 'none', code: 'E111' ...}]
, this second option good side is that it would be already in the format linter is expecting it. I'm just thinking do I gain anything if I have to filter the messages in linter-julia side anyways (like ignoring some error codes).
I think we would want to go with one JSON that has an array of messages, right?
@davidanthoff yes this is my second option. Thus you think it's better? I think it should be relatively easy to implement, I just need second opinion, because I haven't decided which one is better.
Yes, I think that is better, otherwise we need another "protocol" that defines how different JSON messages are combined.
CI is failing on 0.5
I guess CI is failing, because I haven't updated the REQUIRE file to demand JSON dependency. I will add it to next commit.
@davidanthoff and @TotalVerb this is ready for the final review.
Few questions:
"vscode"
style output ok for now?git remote add upstream https://github.com/tonyhffong/Lint.jl.git
git checkout master
git fetch upstream
git merge upstream/master
git push
FYI: here is the linter-julia code version that uses this version: https://github.com/TeroFrondelius/linter-julia/blob/JSON/lib/linter-julia.coffee
We're still using readthedocs for documentation, while most packages have moved to Documenter. So I can't help with that.
I now have a problem with linter-julia json parsing. I need to study what changed.
@TotalVerb thanks, once again, your valuable comments. I will make the changes. If you wouldn't mind taking another look (or even testing) where is my bug. I had this already working with linter-julia, but then I introduced a bug somewhere, which I haven't been able to find. It can be trivial because there are not so many changes between the working commits and non working.
This is the comparison to working version and current, changes in Lint.jl: https://github.com/TeroFrondelius/Lint.jl/compare/1ccc0e9353817de6b1e4173e72b55df195a82882...TeroFrondelius:JSON
and in linter-julia: https://github.com/TeroFrondelius/linter-julia/compare/db8daf9...JSON
I think I found my bug: https://github.com/TeroFrondelius/Lint.jl/compare/a81d069...TeroFrondelius:ddefddb
if haskey(dict_data,"show_code")
if !dict_data["show_code"]
msgtext = "$evar: $txt"
end
else
msgtext = "$code $evar: $txt"
end
The bug is the case when "show_code" = true
@tonyhffong or @Michael-Klassen, I think this is ready for merge. @TotalVerb thanks for your help, please comment if there is still something to do.
@TeroFrondelius The merging of #179 has resulted in some merge conflicts; could you resolve those?
Yes, I will try.
BTW I changed in REQUIRE: julia 0.5
For some reason, Travis did not run. Could you try closing and reopening this PR to restart the CI?
This pull request is ready.
TODO:
See issue #131 Maybe it's ok to list the old issue here to get it closed: #70
@TotalVerb and @davidanthoff your comments / improvement ideas would be appreciated.
Ps. I still haven't learned the git. Now it shows all the commits also for the previous pull request.