log files should be disabled by default

[gokcehan]

It has been suggested in #726 by @desbma that log files should disabled by default. I liked the sound of this idea and wanted to add some mental notes here before making a decision.

I assume we are talking about adding a command line parameter -log instead.

• One of the considered use cases of log files were bug reports by users, though most users are not even aware of these and they are rarely used. Also, the probability of log files having something useful is not that high. So these are more useful for development.

• At some point, we started removing log files on successful exit which is a strange mechanic to have. The idea was to keep log files for crashes in case they are hard to reproduce. This made it more difficult to inspect log files for non-crashing cases. You either need to display it in a separate terminal or use a keybinding to display it in a pager. The former may require looking up the pid and the latter adds extra entries to the log. Not big issues but still annoying to some extent.

• There were cases where log removal mechanism failed to work. For example, closing the terminal while lf is still running which I think is handled properly at this moment. But I think there are cases which are not handled properly. For example, as far as I'm aware, we still lack a mechanism to interrupt file copying and the preferred method is to kill the process and kill -9 seems to leave behind a log file. Also on windows, log removal mechanism does not seem to work at all (bug?).

• If we take the path of the log file as argument in -log we would not need to decide a place for log files ourselves. After the likely xdg patch Use xdg runtime dir for socket and logs #726 , logs will likely be placed in different places on different machines, so if we were to ask a user about a log file in an issue, it would be harder to determine the exact path. Or at least when the path is explicit, log files should be easier to find. Also this would align well with our other development command line parameters for profiling (i.e. cpuprofile and memprofile).

• Users do not like random files popping up in their filesystems which is understandable.

At this point, I can only think of a single disadvantage.

• Log files serve as a message history for cases when a message overwrites a previous message. An example use case for this is errors during file copying. We currently display the number of total errors beside the last error message if there are multiple errors. The idea is that a user can look up other errors from the log if desired.

I don't know whether or not this last point is useful in practice. Personally, I don't remember looking up previous copy errors from the log myself. Also, we might be able to add this without using a log file later on if desired. For example, I was thinking we could store log messages in a string and export them in an environment variable (i.e. $lf_log) so that users can use a shell command to display the log (i.e. echo $lf_log | less). I'm sure there are better alternatives.

Are there anything else beyond the above points? Discussion is welcome.