Hi,
I'm looking how to fix this famous bug without too many changes, and found something strange: tools.c runs it's command with spawn async, but uses blocking I/O to read the data from stdout/stderr.
Any idea why is that? What comes to ming is blocking Geany until the command finishes, to be sure that the current document still exists and it's selection is unchanged, and thus can be safely replaced with the command output.
However, if we block reading stderr on Windows, and the command outputs 4KB (or whatever is the limit) to stdout, that'll cause a deadlock, as evident by the previous messages in this thread. Same if reading stdout and the command produces a lot of stderr, though that's unlikely.
I can emulate the (non-)blocking behaviour, but am not sure if this flag currently has any effect under Windows, considering it's buggy implementation of g_io_add_watch and g_io_channel_set_flags for pipes (which are the problem to fix in the first place).
If tools_execute_custom_command really wants to block Geany, the right thing is to spawn the command, and then cycle reading stderr and stdout asynchronously until the command completes, instead of adding I/O watches to the message loop just to block it.
The current loop that writes the selection to stdin seems capable of causing a deadlock under Windows too, if the command generates 4KB output and stops before the full selection is written, since we use blocking I/O to write to stdin...