<mataniko>
Basically the part is queued and executed before the message queue
<mataniko>
It looks like there's some queue management since the messages never come out of order
<mataniko>
In the meanwhile I just don't join/part
<dominikh>
well, it's not quite the same issue. that issue wants to circumvent all queues; your issue is that we have two separate queues, one for PRIVMSG to a channel (one queue per channel, in fact), and a queue for all other commands
<mataniko>
Ah
<dominikh>
so you get FIFO for messages, you get FIFO for commands, but you get no relationship between the two
<mataniko>
What about a Queue/Transaction wrapper
<dominikh>
Don't hold your breath, Cinch is pretty much unmaintained nowadays
<dominikh>
I don't see it gaining any new API
<mataniko>
ok. Thanks for confirming.
<dominikh>
however, one easier solution might be to put channel-specific commands in the same per-channel queues
<dominikh>
if you take a look at lib/cinch/message_queue.rb, def queue, you see that we special case PRIVMSG and NOTICE, and put everything else in a generic queue
<dominikh>
you _may_ be able to just add "PART" to the same list and have it magically work.
<dominikh>
(line 39 indexes the queue hash table via the first argument of the command. that's the channel for privmsg and notice, and it's also the channel for PART)
<dominikh>
(other candidates for that list would be TOPIC, and whatever else acts on channels and has visible effects. e.g. WHO probably wouldn't go in there, scheduling that independently should be fine)
<dominikh>
mataniko: ^^
<mataniko>
That makes sense. I'll take a look
<mataniko>
it's not a big deal if i can't join/part so might just skip it
<dominikh>
it's a one-line change, should be trivial to test
<mataniko>
thanks!
_whitelogger has joined #cinch
Azure has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]