I'll try all of that later, but first let me tell you a bit more about the behaviour that's going on:
* Xkill'ing the window of PyLNP does NOT kill the dfhack window, and it does NOT free the terminal it was launched from
* Pressing Control-C in the terminal I ran PyLNP from kills both the PyLNP window and the DFHack window
* Neither of these things kills DF itself
This would indicate that both the DFHack window and the PyLNP window are children of the terminal they were spawned from
Furthermore:
* The PyLNP window itself hangs, but neither the DFHack window nor the DF window themselves hang
Other than that, I think you're using i3-msg wrong, because it's intended to be used for IPC between something and i3wm.
Also, i3-msg has no --no-startup-id option.
Also, from some small tests on the command line here, the correct syntax appears to be "i3-msg exec 'i3-sensible-terminal -e $command'". Important is that $command doesn't exit immediately (for example, entering 'ls' in the place of $command will immediately exit, while entering 'vim' means it will stay alive. Strangely enough it also immediately exits when entering 'ls | less', while it shouldn't)
Lastly:
kahr[~]>export | grep i3
DESKTOP_STARTUP_ID=i3/i3-sensible-terminal/575-14-K-02_TIME59928497
I'm sure there is a way to know if i3 is running, because things like screenfetch can accurately show it. A cheap hack would be to just check if 'pidof i3' returns something and hope the user is not weird enough to have something running by the name of i3 that is not i3wm.
EDIT: seeing as how --no-startup-id is not an option on i3-msg, and because i3-msg exec vim only prints '[{"success":true}]' without spawning anything, I think i3-msg exec 'i3-sensible-terminal -e "$command"' should be the right syntax, which I'll try out shortly after I save my DF game.
When testing that but substituting $command with 'vim', I can also see that it gives control back to the terminal it was launched from, so this looks promising.
Note however that if i3-sensible-terminal does not evaluate to urxvt, it's syntax might be different (it might not use the -e for example) and everything will break.
EDIT2: A little correction on my earlier bug report: utilities set to auto excecute don't excecute after PyLNP exits, but after DF exits. Of course, there is no reason why I would want DwarfTherapist to run *after* I'm done playing DF, so that's a bug.
EDIT3: Okay, I changed the line in xdg-terminal, and I did a little test by running './xdg-terminal vim'.
It shows some odd results: It appears to only partially give control back to the terminal it was launched from: I can type 'ls' (or any command, also tested with 'exit') in that terminal, and nothing will happen, but when I close the vim window spawned, ls will excecute.
I doubt this is going to work, but I'll compile it and test it anyways. I'll also provide those log files you asked for.
EDIT4: Okay, results:
* PyLNP still goes unresponsive
* Control-C'ing in the terminal PyLNP was launched from still makes the DFHack window exit
Basically, nothing changed.
None of the log files (stderr.txt, stdout.txt) contain anything either, any the pressing of Control-C only gives the standard KeyboardInterrupt traceback.
EDIT5: Here's the output of pstree:
http://pastebin.com/U7FGcjV5The relevant part is beneath upowerd
Interestingly, apparently when I press Control-C in the terminal only once, only dfhack exits and the PyLNP window becomes responsive again, and when i press Control-C again, the PyLNP window closes too (I always spam Control-C so I never noticed this)
Another interesting thing: because DF is a child of DFHack (after all, the dfhack script launches DF), this means that DFHack doesn't really exit when it's window is closed.
Very interesting.
EDIT6: Okay, so I got in a situation where:
* PyLNP is killed (using pkill PyLNP)
* DFHack's window is still alive
* DF is still alive
For now, a fix appears to be to manually pkill PyLNP, then manually restart it