Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error/warning count in output #655

Closed
mattgarrish opened this issue Nov 30, 2015 · 3 comments · Fixed by #742
Closed

error/warning count in output #655

mattgarrish opened this issue Nov 30, 2015 · 3 comments · Fixed by #742
Labels
status: has PR The issue is being processed in a pull request type: improvement The issue suggests an improvement of an existing feature
Milestone

Comments

@mattgarrish
Copy link
Member

I was just doing some work on generating an epub from the specs and got to thinking it would be nice to see the total error/warning count after the message that the file contains errors.

When I'm tweaking xslts, it's not always clear if I've fixed the problem without scrolling back through all the messages output to the console. A count would at least give me a quick visual whether things have gotten better, worse or stayed the same.

Anyway, another of my non-critical feature requests...

@mattgarrish mattgarrish added the type: improvement The issue suggests an improvement of an existing feature label Nov 30, 2015
@tofi86
Copy link
Collaborator

tofi86 commented Jan 4, 2017

While this is very easy to implement as Check finished with 5 warnings, it may break all those tools which rely on or grep the message Check finished with warnings / Check finished with errors.

Therefore I would suggest to include a message counter at the very end like this:

Current:

…

Check finished with errors

epubcheck completed

Suggestion:

…

Check finished with errors

0 fatal errors
3 errors
5 warnings
2 informations
10 usage messages

epubcheck completed

or in a one-liner:

messages: 0 fatal errors / 3 errors / 5 warnings / 2 informations / 10 usage messages

What would you prefer, @mattgarrish?

@mattgarrish
Copy link
Member Author

mattgarrish commented Jan 4, 2017

I'd vote to save space and go with the latter. The more actual errors you can read from the command line without scrolling the better.

You could maybe save some further space by trimming to:

messages: 0 fatal / 3 errors / 5 warnings / 2 info / 10 usage

@tofi86 tofi86 added this to the Next milestone Jan 5, 2017
@tofi86 tofi86 self-assigned this Jan 5, 2017
@tofi86 tofi86 added the status: has PR The issue is being processed in a pull request label Jan 5, 2017
@tofi86
Copy link
Collaborator

tofi86 commented Jan 5, 2017

I implemented this in PR #742.

However, I had to make changes to the Report interface so don't expect this in the next Bugfix release. Should be next Minor or Major release...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: has PR The issue is being processed in a pull request type: improvement The issue suggests an improvement of an existing feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants