Rethink debug logging

[progfolio]

The current method of adding debugging logging to every function call is fragile and doesn't scale well. Firstly, it requires that you add the debugging code to every function (so far 55 instances, ~200 LOC), which significantly adds to the code base. Secondly, it requires that each instance remain in sync with the function's signature.

A better approach would pick spots where logging would be most effective and log from there. e.g. lower-level functions which other functions build off of (syncthing-request, for example). The kind of granularity the current logging attempts is better served by stepping through the code with a debugger.

[KeyWeeUsr]

Yes and no because Emacs isn't used just by programmers, so if somebody stumbled upon an issue here, operating a debugger might not be an option and the debugging details might be just "it doesn't work". The way it's done is so that there's a way to reproduce it and possibly dump it straight to a test case just by having the same func calls traceable. However, I agree it isn't scalable for sure, but I haven't found a way to dump a full code trace in lisp yet.

In other languages I'd make a decorator or have a debugger simply log the call trace. Unless there's some way to do it with edebug or likes then with Elisp I'm thinking about something like (with-trace ...) similar to (with-temp-buffer ...) to make it prettier though I'm still missing a way to pull the func name and its args. Any idea how?

[progfolio]

Yes and no because Emacs isn't used just by programmers

I don't think the complexity of the program will require significant logging. Users hitting an error can be told to M-x toggle-debug-on-error and copy the backtrace. This is the standard way to get a trace when an error occurs. I would start simple and only implement your own logging if you end up needing it.

I haven't found a way to dump a full code trace in lisp yet.

That's the job of the debugger.

[KeyWeeUsr]

toggle-debug-on-error doesn't always work and especially not for when an exception is silenced/handled.

The idea behind these logs isn't to have it just for some funcs. It's to have a toggle which will enable emitting of what the program is doing without any interaction of the user but setting one value and then unsetting it. In other words a call recorder similar to other types of programs having a signal handler which if triggered will either dump logs, restart or other behavior.

[progfolio]

toggle-debug-on-error doesn't always work and especially not for when an exception is silenced/handled.

It works unless the error is explicitly handled/ignored. Errors should rarely be ignored, and the cases where they're handled should be well defined.

It's to have a toggle which will enable emitting of what the program is doing without any interaction of the user but setting one value and then unsetting it

That's essentially what the debugger is in the case of errors. There's also the profiler for cases concerning performance.

I understand the intent. I don't agree it's a good design decision. A happy medium would be to implement logging in a few hot, low-level functions. Those log entries would be better placed in their own buffer than *Messages* as well.

[KeyWeeUsr]

Alright, so we don't agree. :man_shrugging: The idea of a separate buffer for the dump is good, I'll put it there.