The BashBugDump is very helpful, but has one huge downside: activating it gets rid of the 'native' error reporting mechanism (most notably wxPython's popup window), which means you have to remember to check the BashBugDump every time you close WB.
We enabled the BashBugDump by default for standalone builds a while ago, but by doing so, lost wxPython's error reporting. This makes it harder for users to notice when something is broken.
The solution is to copy the output to both the BashBugDump and the 'native' stderr stream. With that done, there is no more point to having the 'debug mode' toggle in the settings or the -d CLI argument, so they can be removed. We may reintroduce a debug mode later when we rework logging (see #352), so let's keep the -d parameter around (that also means any existing scripts/shortcuts/etc. that launch with it will continue working).
The BashBugDump is very helpful, but has one huge downside: activating it gets rid of the 'native' error reporting mechanism (most notably wxPython's popup window), which means you have to remember to check the BashBugDump every time you close WB.
We enabled the BashBugDump by default for standalone builds a while ago, but by doing so, lost wxPython's error reporting. This makes it harder for users to notice when something is broken.
The solution is to copy the output to both the BashBugDump and the 'native' stderr stream. With that done, there is no more point to having the 'debug mode' toggle in the settings or the
-d
CLI argument, so they can be removed. We may reintroduce a debug mode later when we rework logging (see #352), so let's keep the-d
parameter around (that also means any existing scripts/shortcuts/etc. that launch with it will continue working).