@techee
In my opinion, the whole prefix of the message that should be removed [...]
I can remove the "FunctionName() failed:" from the spawn module. The other prefixes, if any, are added by the callers.
ui_set_statusbar(TRUE, _("Cannot execute grep tool '%s';" " check the path setting in Preferences.")
This is indeed user friendly, but tells us absolutely nothing about why grep failed. My suggestion above was to maybe display a user friendly message, but also put the full text in Status or Debug -> Messages.
If we are going to display something like this, with no information from the actual GError message, there would be no reason to touch the spawn module...
(BTW, this particular message was not correct, unless you read "cannot execute" very widely: it was produced if g_find_program_in_path() failed, and the execution itself was about 60 lines below, with a completely different message.)
_("Could not parse terminal command "%s" " "(check Terminal tool setting in Preferences)")
spawn_async() parses the command line and reports any errors in more detail. It also rejects insecure program names under Windows, which is not really a parsing error.
TL;DR:
Now, if I also remove the parsed command text from the spawn GError, leaving only the error description text (my 2nd suggestion), these may be unified and become:
Cannot execute grep tool "%s": <error>. Check the path setting in Preferences. Cannot execute terminal command "%s": <error>. Check the path setting in Preferences.
For example:
Cannot execute grep tool "c:\msys32\usr\bin\grep.exe": The system cannot find the file specified. Check the path setting in Preferences.
Cannot execute terminal command "": Text was empty (or contained only whitespace). Check the path setting in Preferences.
Seems pretty reasonable to me.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/541#issuecomment-147111111