Add config option lessVerbose

[srguiwiz]

This is for issue #127 .

When not used, nothing changes compared to previous behavior.

One could think of the function name infoV to mean infoVerbose.

[szymmis]

Hi @srguiwiz, great change! Thanks for submitting a PR for that.
I think that we don't really need infoV function: we can just add the verbosity check into the info function itself with the parameter stating what verbosity level it is printed in. Then instead of having lessVerbose as a boolean we can have an enum to choose from, so let's say that Verbosity.Silent is 0 and Verbosity.Normal is 1. As it is a number we can just compare the current verbosity with the one stated in the parameter.

If we have Verbosity.Silent we only want to print if info("msg", Verbosity.Silent) but it should also be printed in higher verbosities.

I think that the example will make that clearer:

enum Verbosity = {
  Silent = 0,
  Normal = 1
}

function info(msg: string, verbosity = Verbosity.Normal) {
  if (Config.verbosity < verbosity) return;
  ...
}

And then you can only change places when you left info without changes as I suppose those are the places when you want to print messages even with verbosity tuned down. We can even introduce third level of verbocity, that way Verbosity.Silent will be no messages at all.

Tell me what you think!
Again, great suggestion right there, thanks a lot!

[srguiwiz]

I don't disagree. After reading your comment I had spent a short amount of time thinking of something optimal. But, time can be short in supply. By now I forgot what I had thought.

Thinking of future compatibility without spending more time: If you would merge as is, then a future implementation could choose to take a truthy value in lessVerbose and use it in its newer and improved ways. I think, almost sure, but I could be wrong.

Btw, the specific style of coding was chosen for minimal diff. Not saying that is always the best choice. It was what I had thought that moment would be the least intrusive. If it had been "my" project I'd probably have chosen different constructs, which the moment I was about the type them I thought they would cause a bigger diff.

I would not be offended if you reject this PR and implement it differently. It's all good.

Thank you

[szymmis]

Hi @srguiwiz. Sorry for leaving it for so long. I've finally found some time to sit down and make the changes I was talking about. I totally get your point of view of wanting to change as little as possible. It was not necessary to reject the PR itself as your idea and code were good starting point for my improvements, so thank you very much for suggesting this feature and taking your time to implement it.

I don't know if you are still interested in it as a long time have passed but I hope so!
If yes, then let me know what you think about this change.
I plan to release it soon, but I would also like to tackle this issue in one release.

[srguiwiz]

@szymmis, thank you for your thoughtful implementation. And yes, this is still a useful package.