Ticket created by ~delthas on ~emersion/soju
see https://github.com/emersion/soju/blob/master/conn.go#L82 ; the read/writeDeadline are plain structs but the methods are not accessed thru a pointer receiver
Comment by ~delthas on ~emersion/soju
We currently only do highlights coming from donwstream
Comment by ~delthas on ~emersion/soju
I think we should only support whole-word matches. So if people call you by your nick without spelling it properly or by adding a few letters it won't be replaced. If you expect to be called taiites in the first place you could add a rule in your client I guess
enhancement added by ~delthas on ~emersion/soju
Ticket created by ~delthas on ~emersion/soju
In multi-upstream mode, if someone mentions a user and his upstream nick is different frm his donwstream nick, he won't get any highlight notification from his client.
Replace mentions of the user upstream nick with the downstream nick.
eg
upstream incoming: PRIVMSG foo #bar :sojuupstream: hi downstream outcoming: PRIVMSG foo/server #bar :sojudownstream: hi
Ticket created by ~delthas on ~emersion/soju
Trying to escape # will prove difficult I think and cause more pain than anything (# should be quoted when not already escaped, except in single-quotes where nothing can be escaped, but single-quotes can be themselves escaped or appear in double-quotes, etc). I think we should just re-implement a simple quoted strings parser, it's not that much work.
Let's leave this for another PR though.
Ticket created by ~delthas on ~emersion/kimchi
- Connect timeout (10s?)
- Reponse timeout (how much? customisable?)
Ticket created by ~delthas on ~emersion/kimchi
e.g.
errors { 404 /index.php }
Ticket created by ~delthas on ~emersion/kimchi
e.g.
index asdf.html
Comment by ~delthas on ~emersion/soju
Exactly. In cases where my connection is unstable and the TCP connection repeteadly breaks, I'd like to soju to ensure that I did receive everything before dropping it. In other bouncers that simply fire & forget the history, these messages are lost.
But it's true that for example when a client that has not connected in 12 months reconnects, it'll receive so many messages it might actually freeze, the user might kill it, and then he'll be stuck in this situation. I suggest sending perhaps 1 PING every 1000 messages + 1 at the end. Thoughts?