Reproduced with permission: 13:56 < madduck> can i paste this discussion into the bug log? 13:56 < schmorp> sure
from #schmorp/freenode: 13:52 < schmorp> well, it just blindly removes all -wait's from the arguments 13:53 < madduck> you mean it should only honour the first one and pass all other ones onwards? 13:53 < schmorp> and apart from likely being useless 13:54 < madduck> well, it's not useless, given http://bugs.debian.org/481123 13:54 < madduck> on debian, urxvtcd cannot be x-terminal-emulator anymore 13:54 < schmorp> well, that bug got fixed without your patch 13:54 < schmorp> so your patch isn't useful to fix the problem 13:54 < madduck> and one urxvtd process serving 50 windows is likely to be less resource-intensive than 50 urxvt instances, no? 13:54 < schmorp> no 13:55 < schmorp> well, yes 13:55 < schmorp> but that's not wht your patch does 13:55 < schmorp> y<our patch makes one process with 50 windows, and 50 processes without a window 13:55 < schmorp> it also still doesn't behave like urxvt 13:55 < schmorp> e.g. when you kill it 13:55 < madduck> well, no, it only makes 50 processes if those were called with -wait 13:55 < schmorp> that's true, but that'S cheating 13:56 < madduck> when i kill the client, the window stays, you are right. 13:56 < schmorp> because if those 50 windows are not started using urxvtcd 13:56 < schmorp> then your argument becomes meaningless? 13:56 < schmorp> because you cna do that already without your patch 13:56 < schmorp> but the bug is alredy resolved 13:56 < madduck> so i shall just put my work there and then we'll see where it goes 13:56 < schmorp> in a sensigle way 13:57 < madduck> kinda, it's left as a wishlist. 13:57 < schmorp> you really should first find out 13:57 < schmorp> whether your patch actually helps 13:57 < schmorp> so far, there are a lot of known disadvantages 13:57 < schmorp> such as it completely breakign commandline parsing 13:57 < schmorp> and no known advantages 13:58 < madduck> how does it completely break command line parsing? 13:58 < schmorp> it removes all occurances of -wait 13:58 < schmorp> urxvt does not, it treats -wait properly 14:02 < madduck> how about not parsing but waiting if called as 'x-terminal-emulator'? 14:02 < schmorp> that is even worse 14:02 < schmorp> now you get magic behaviour depending on what the caller passed as name 14:03 < madduck> but callers of x-terminal-emulator expect it to wait 14:03 < madduck> assuming the client can communicate to the server when it gets killed and the server subsequently destroys the window, then that's it. 14:04 < schmorp> the bug is fixed in a 100% working way 14:04 < schmorp> your patch doesn't even work for all callers of x-terminal-emilator 14:04 < schmorp> you would have to check the name the parent was called with, or the name the program itself was called with 14:04 < schmorp> which is pretty difficult 14:04 < madduck> i see 14:05 < schmorp> what i fail to see 14:05 < schmorp> is why you try to fix what's not broken 14:05 < schmorp> especialyl since the memory savings are unlikely to be there 14:05 < schmorp> in any case, only urxvtd knows how to parse the args 14:05 < schmorp> so you would have to add --wait parsing there 14:05 < schmorp> and then communicate to urxvtc that it should wait 14:06 < schmorp> which is basically what you alraedy do with RUNNING 14:07 < madduck> okay, I will conclude this for now 14:07 < madduck> you have good arguments 14:07 < madduck> and i think i will just switch to urxvt 14:07 < madduck> but i don't want to throw all this away, so I will forward patch and this discussion to the bug log. 14:09 < schmorp> sure -- .''`. martin f. krafft <madd...@d.o> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
