Forgot to reference #3 :)

thanks a lot, I'm leaving some comments

By all means; all of the above oddities derived from me avoiding changing the existing API. If you feel like changing APIs there are much cleaner ways to expose the required functionality without kludges.

For e.g.: Logger.IsEnabled is a boolean field, and I assumed it should be kept for client programmers to rely upon, so I created a hidden method to take over for internal code, and update IsEnabled as a side effect to help client code.

If I were breaking the API, I'd just drop the IsEnabled field and replace it with a method that does what amIEnabled does.

Likewise the Enabled() function could be removed if the enabled map were public, and we could dispense with getters and setters entirely. :)

@cathalgarvey I think we can change the API little bit. This PR will enable logger to be used programmatically for first time, so it's ok change things for good looking API. Thanks a lot!

Looking over Logger's importers on Godoc: https://godoc.org/github.com/azer/logger?importers

..Looks like nobody is using the sections of the API that I'm changing here. Well, maybe you are but I'm not looking at your other projects, because it's your API to break. :)

So we're safe.

I have not yet tested this, I'm just pushing while in-progress.

Big changes:

• Exposed Enabled, AllEnabled, Verbosity.
• Verbosity is now a custom int type with three constant levels provided, private type.
• Logger now has a new method, IsEnabled() bool, to replace the old attribute. It doesn't look like any clients of this library were using or relying on the attribute, at least according to godoc. I removed the global IsEnabled function.
• New(name string) *Logger now adds name to the Enabled map if not already present, with default value of false. This exposes a minor race condition, but to resolve this would require hiding Enabled and using getters, setters, and sync.Mutex; because this is a logging package I figured the risk is low, but given the JSON portion of the API it's possible this would be used for (important) Telemetry, so maybe mutexed get/sets for Enabled are the best way to go? With your permission I'd rather hide Enabled again and mutex it with a getter/setter.
• Small changes where I thought they made sense; eg:
  removed what looked like a redundant if in PrettyPrefix and an overkill fmt call.

Other:

• I added some comments to document stuff
• I added some thoughts to the JSON encoding bits, because it looks right now like they may be vulnerable to invalid data, and because I think they could be more maintainable as a call to json.Marshal, possibly with the addition of a private struct to handle the intermediate representation or using an anonymous struct.
• My metalinter plugin auto-changed some tiny formatting stuff (sorry)

Next steps:

Derp, typo posted early.

Next steps I'd recommend:

• Make choice between pretty printing and JSON an explicit developer choice, with the default choice being "decide dynamically" (e.g. as things are right now) and other choices being to either always JSON or always prettify the output.
• Make some tests..
• Change the JSON handling code to rely on json.Marshal

sorry for late merge, thanks for the PR 👍

@cathalgarvey I can add you as collaborator if you'd like to merge your PRs quicker