I reworked JWW into a simple Notepad structure that more or less handle all the job by itself.

The old interface of JWW is almost conserved, using a Notepad created in the init() and whose loggers are linked to exported vars, and relinked when changes occurs. I'm not really satisfied by this solution, but it's simple and efficient, and leave the external API clean.

There is one API break, that is to take a io.Writer instead of a path for the log output. I feel it simpler and it evacuate the need to check for errors in the lib, and enable the end-user to do some really cool things quite simply (like logging to a database, etc).

I also enabled the user to choose flags and an optional prefix, like the original log.Logger struct… it is useful to distinguish two Notepad's outputs.

The x/vgo prototype enforces strict casing on imports. spf13/viper imports spf13/jwalterweatherman, which is not the same casing as the github repo. This breaks importing the library.

Arguably vgo should not be enforcing case. However, even you, the author, don't use the correct case, which suggests to me maybe in this case the github repo should just be renamed to what people actually import it as. WDYT?

This is related to a comment that @owenwaller left in his updated hugo/utils_test.go: https://github.com/spf13/hugo/pull/818

Is modifying UseTempLogFile() so that it returns the temp filename a change you would support? If so I can make a pull request.

The default settings do not work correctly for nested key. My patch (viper.go):

// Test for nested config parameter
    if strings.Contains(key, v.keyDelim) {
        path := strings.Split(key, v.keyDelim)
        source := v.find(path[0])
        if source != nil {
            if reflect.TypeOf(source).Kind() == reflect.Map {
                val := v.searchMap(cast.ToStringMap(source), path[1:])
                if val != nil {
                    jww.TRACE.Println(key, "found in nested config:", val)
                    return val
                }
            }
        }
    }

Hi, we updated some exported function comments based on best practices from Effective Go. It’s admittedly a relatively minor fix up. Does this help you?

    switch config.GetInt("LogLevel") {

25 case 0: 26 jww.SetLogThreshold(jww.LevelError) 27 jww.SetStdoutThreshold(jww.LevelWarn) 28 case 1: 29 jww.SetLogThreshold(jww.LevelWarn) 30 jww.SetStdoutThreshold(jww.LevelInfo) 31 case 2: 32 jww.SetLogThreshold(jww.LevelInfo) 33 jww.SetStdoutThreshold(jww.LevelInfo) 34 case 3: 35 jww.SetLogThreshold(jww.LevelDebug) 36 jww.SetStdoutThreshold(jww.LevelDebug) 37 default: 38 jww.FATAL.Println("Invalid debug level specified:", config.GetInt("LogLevel")) 39 } 40 jww.SetLogFile(config.GetString("LogFile"))

Results in a ./archit.go:40: undefined: jwalterweatherman.SetLogFile compilation error. All the other functions appear to compile fine.

FEEDBACK logger always outputs this logger's file name and line e.g.

thatswhyyoualwaysleaveanote.go:175 (FEEDBACK.Println) thatswhyyoualwaysleaveanote.go:183 (FEEDBACK.Printf)

to a log file.

Instead of it, this makes FEEDBACK logger output its caller's file name and line to a log file to provide more useful information.

Prevent client applications from having to deal with text being forced to their stdout by using INFO rather than fmt for output.

I wanted to prevent JWW from output text in my application, this seemed like the easiest way. The other idea I had was a SilenceInternalOutput() method which would disable any fmt.Println() calls, while not breaking any existing applications which might enjoy the fact that they were getting "Logging to file ..." messages in their stdout. Would be happy to rework to that if preferred.

The logging flag was fixed. Set it as default

(log.Ldate|log.Ltime|log.Lshortfile)

So I have added an API to set the Flag as per requirement.

func SetLogFlag(flags int)

And added a abstraction over log flags:

DATE     = log.Ldate
TIME     = log.Ltime
SFILE    = log.Lshortfile
LFILE    = log.Llongfile
MSEC     = log.Lmicroseconds

Hello! Looking at source code for the jww library I've seen 2 more levels ( LOG and FEEDBACK ) available ( aparte from the 7 explained in readme ).

Is is possible to set log threshold to one of these?

Thanks for the feedback ( and your work )!

For clients using the "log counting" feature, this will be slightly breaking. But it adds lots of flexibility which should make it worth while.

Now you can supply one or more LogListener funcs when creating a new Notepad. Typical use cases would be to capture ERROR logs in unit tests, and to count log statements. A listener for log counting is provided, see the LogCounter func.

If you want to add listeners to the global logger, see SetLogListeners.

Adds colored output to stdout. Doesn't support file-loggers atm (you'll get this [DEBUG] debug.go:16: DEBUG, I don't know how to use the old prefixes when writing to a file)

Exposes a method notepad.UseColor(), UseColor() and a parameter in NewNotepad.

With colors:

Also exposes the colors so people can use them in their messages, if they wish. (jww.DebugColor.Println("color"))

I'd like to align my console log by making all log levels four characters wide. It would be nice to make the prefixes map public API, preferably per notepad.

Hi, we updated some exported function comments based on best practices from Effective Go. It’s admittedly a relatively minor fix up. Does this help you?