Message level: error, warning, info
lassik opened this issue · 9 comments
(Continuing from #163)
While I don't personally care which checks are errors and which ones are warnings, I'd argue against adding more message levels (info, notice, debug, etc.) on the grounds that they get more confusing with each new level. C compilers emit a particularly large variety of messages, and those are only grouped into errors and warnings. It works great.
Compiler message levels are easy to grasp: errors stop the compile, warnings don't (unless you manually use -Werror). The same criterion could be good for package-lint: Something that would block a MELPA submission is an error; advice that doesn't block submission is a warning. If warnings exit with code 1 and errors with code 2, it could even be tied into the new MELPA scripts that are just being experimented with (ping @riscy).
As background, Dave Cheney has a funny, polemical essay arguing there should only be two log levels: https://dave.cheney.net/2015/11/05/lets-talk-about-logging
It's written from the point of view of messages that programmers should read vs messages that users should read.
Compilers have messages that stop the build vs messages that don't stop the build.
Package-lint could have messages that are MELPA blockers vs messages that are not MELPA blockers.
The point is that log levels that can be toggled on and off should make us question who the target audience is, and whether there is one to begin with. If there is, how can we target the messages to them more obviously?
In the compiler and linter case, the two target audiences are fussy programmers and sloppy programmers (to use humorous terminology matching the tone of Dave's blog post). The two camps are traditionally in opposition, and that may be the crux of the matter. Coders often move from camp sloppy to camp fussy with increasing experience or responsibility. For example, C programmers gradually turn up the warning level in their compiler.
This all seems like quite the mountain for a molehill comprised of one person who refuses to capitalize a single letter in a comment in his package.
How much could have been accomplished if the time spent arguing about capitalizing one letter had been spent on something else. Just M-c and move on.
You're right. I think his deeper concern was that us MELPA folks are adding our own checks on top of GNU's elisp coding conventions while the package goes by the generic name package-lint. It never occurred to me that it should be limited to particular conventions, but should simply offer warnings that are useful.
@purcell also mentioned in #163 that he's thinking of adding info, which motivated this issue.
You're right. I think his deeper concern was that us MELPA folks are adding our own checks on top of GNU's elisp coding conventions while the package goes by the generic name
package-lint.
That may be so, nevertheless, MELPA is by-far the largest Elisp package repo and the one that's been leading the way for years. I don't think it's a crime against "convention" for it to call itself package-lint instead of melpa-lint and have its own, slightly higher standards than the lowest-common-denominator ones that emacs-devel can agree to.
I would generally suggest that someone who wants strictly minimal, emacs.git-official standards should make a new linting tool and merge it into emacs.git or ELPA, rather than trying to make package-lint change. Of course, Steve, et al. should do what they think is best, and I trust their judgment.
package-lint is very much specific to MELPA, and afaik there's basically no review of ELPA packages for the same kinds of issues.
All the checks I've added to package-lint reflect things I care about for packages in MELPA, so yes, it's basically a linter for MELPA purposes. If other people find it useful, then that is because it grew out of MELPA! :-)
I never want to end up in that daft (IMO) situation where there is a granular mechanism for enabling/disabling particular lint items according to taste.
However, I'd consider having a "MELPA" vs "non-MELPA" mode for package-lint, where a certain set of checks would be demoted (or skipped) in non-MELPA mode. The trouble is, I really don't care about non-MELPA mode, and I'm not sure that any particular group of people would ever be able to agree on what that set of checks should be!
Regarding this issue itself, I agree that adding further levels (info, notice etc.) isn't particularly helpful if they don't have a clear meaning, and I'd also prefer to stick to error/warning only.
How about always outputting the same messages, but tagging each message with the name of the conventions or recommendations it comes from? E.g.
Replace deprecated 'cl' with 'cl-lib'. The 'cl-libify' package can help with this. [Emacs Lisp Coding Conventions]
That still leaves the question of warnings vs errors.
How about making everything be an error, but having a different interactive command for MELPA mode and "ELisp Coding Conventions only" mode?
Probably for this one I'm going to stick my head in the sand and just focus on keeping this useful for MELPA reviewers and authors. I have no idea what should be enforced or not for GNU ELPA.
tagging each message with the name of the conventions or recommendations it comes from
I do like the idea of pointing people at the elisp conventions when that's the source of the recommendation, yes.