04:37 <leftylink> let's say the bot is voiced on ##leftylink (on let's say freenode), and someone sends a message to the channel +##leftylink to send a message to all voiced (and above) users. now, cinch sees that message just fine, there's a log line for it and everything

04:37 <leftylink> [2015/10/25 04:16:47.947] >> :leftylink!~leftylink@unaffiliated/leftylink PRIVMSG +##leftylink :!whatchannel

04:38 <dominikh> let me guess, it thinks the channel is named "+##leftylink"

04:38 <leftylink> however, when it comes time to look at the message, Message#channel is nil on that message, presumably because https://github.com/cinchrb/cinch/blob/master/lib/cinch/message.rb#L250 won't take it. I'm wondering... should it be accepted?

04:39 <dominikh> pretty sure that sending a message to "+##leftylink" is some 3rd party extension and not standard IRC. there's originally no mechanism of sending a message to just the voiced & above users in a channel.

04:39 <leftylink> yeah I don't see it in RFC 2812

04:39 <leftylink> or uh the earlier one

04:39 <leftylink> is it 1459

04:39 <dominikh> (by pretty sure I mean that I know)

04:39 <dominikh> so… I'm not really sure what to think of this

04:40 <leftylink> me neither. does the server expose that it is capable of doing such a thing, and does it even make sense for cinch to support such a thing even if it does

04:40 <leftylink> let's see

04:40 <dominikh> well, it's not using client capabilities to advertise that feature

04:42 <dominikh> well, weechat seems to support it :P

04:42 <leftylink> irssi's relatively fine with it, though it displays... a bit weirdly for me

04:43 <dominikh> I'll look into it.

04:43 <dominikh> would be nice to have a name for this protocol extension

04:44 <leftylink> yeah I'll sleep on it for a bit. as for the name... yeah see there's a single stack overflow answer http://stackoverflow.com/questions/13701298/ that says it's called wallmsg, but I can't find any corroborating statements for it so I am skeptical that is a widespread name

04:45 <dominikh> I don't think that is the correct name for it, as it refers to something else already.

04:46 <dominikh> how'd you find out about said feature?

04:47 <leftylink> hmm, kinda secondhand really, https://github.com/caitlin/cinch-resistancegame/issues/41 - who knows how that person found out about it

04:48 <dominikh> it should also be noted that it already requires permissions to use +#channel – at least it didn't work without op here

04:49 <dominikh> ah, issue says so. requires voice.

04:50 <leftylink> despite this, no skin off my back if cinch isn't going to get in the game of supporting this

04:50 <dominikh> oh I'll support it

04:50 <leftylink> for the purposes of the issue, the response to that issue could just be "it's a social problem - people shouldn't use +#playresistance, it's against the rules"

04:54 <dominikh> it's a bit of an annoying issue because it needs some design decisions, and because I want actual documentation for this feature. it wouldn't be particularly hard to implement -- code-wise

04:55 <dominikh> https://github.com/caitlin?tab=repositories look at all those games for Cinch!

04:57 <leftylink> heh. I have a few myself as well

04:59 <leftylink> it's a bit unfortunate because some networks have + as a standalone prefix in its own right, right? so there could be +channels. so would one have to try to check *two* characters? hmm...

05:00 <dominikh> not that hard to check two characters ;)

05:01 <dominikh> we have to, anyway. we have to check for valid status sigil + channel prefix, or channel prefix

05:01 <leftylink> http://www.irc.org/tech_docs/005.html says WALLVOICES but who knows if that is widespread

05:01 <dominikh> what worries me even more is that I remember a similar feature from quakenet, but don't recall if it uses the same syntax

05:02 <dominikh> it's called STATUSMSG

05:02 <dominikh> it's actually advertised in the ISUPPORT line (STATUSMSG=@+)

05:03 <dominikh> thanks.

05:04 <leftylink> is ISUPPORT only sent on connect or can I see it somewhere after the fact

05:04 <dominikh> only on connect

05:05 <leftylink> ok I see STATUSMSG in freenode's 005

05:05 <leftylink> yeah ok

05:05 <leftylink> trying to teach myself to fish, as it were

05:07 <dominikh> don't fall in the water

05:17 <dominikh> and here the annoying questions begin. Should Message#reply reply to #channel or +#channel, if the message was sent to +#channel?

05:21 <leftylink> I think I might argue in favor of +#channel as it seems more consistent with the behavior of Message#reply with PMs and channel messages

05:21 <dominikh> Yeah.

05:22 <leftylink> another interesting question is whether Message#channel should be #channel or +#channel but it's not like +#channel really exists in its own right, so maybe that would be #channel . does it sound a bit inconsistent... I'm unsure

05:22 <dominikh> I wonder if it's okay to have a method called Message#statusmsg that returns the class of people that were addressed (:all, :voice, :op, ...) – #statusmsg is a bit of a shabby name, but I can't think of a better one right now

05:23 <dominikh> Message#channel will return Channel("#channel") – otherwise plenty of things would break – or need special handling.

05:23 <dominikh> the channel is, after all, still #channel. the + and @ is separate from that

05:23 <leftylink> those who are addressed? addressees, of course! (I might be saying this in jest)

05:24 <leftylink> visible_to

05:24 <leftylink> eh...

05:24 <dominikh> issue with #statusmsg is that it only applies to messages sent to channels, whereas Message applies to any and all IRC messages (mode changes, parts, etc) – the method would only apply to a subset

05:24 <dominikh> the name needs to reflect that

05:26 <dominikh> #statusmsg_mode maybe

05:34 <dominikh> okay, implementing the new #reply semantics is a bit more annoying than I anticipated

06:19 <leftylink> ... oh yeah I can see where that might be weird...

06:19 <leftylink> all these obscure features

06:19 <leftylink> that you might not use yourself

06:19 <leftylink> where do you get the motivation to make them work

06:20 <dominikh> I… don't know.

06:20 <dominikh> "that you might not use yourself": I don't use Cinch at all anymore ;)

06:26 <dominikh> http://sprunge.us/LTFc first iteration of the patch. only makes Message#channel and Message#reply behave as expected. later on I'll need to add new APIs to Channel so that given a Channel("#foo"), you can send a message to @#foo

06:34 <dominikh> and I'm considering not adding the Channel APIs for now; or I won't fix the issue for a couple of days so I can think about it

06:45 <leftylink> many thanks. I'll go and apply it and test it

06:46 <dominikh> oh yeah, that patch is totally untested as of yet.

06:46 <dominikh> it might not even syntax check

07:01 <leftylink> well, Message#channel and Message#reply are what I expect for ##leftylink, +##leftylink, and privmsg to bot

07:01 <leftylink> so this is a good sign

07:03 <leftylink> sometimes I wonder "what if I could test this in some fashion other than manually". but I know, I know, you've expressed your feelings on that many times in this channel

07:04 <leftylink> ... in fact I just ran existing tests and PluginTest has various errors. heh

07:05 <leftylink> maybe soon I'll see if I can even do anything on that front or if it's as bad as you say

07:06 <leftylink> I think sometimes I have to see the badness for myself to understand

07:06 <leftylink> I wonder if many others have embarked on similar foolhardy quests

07:06 <leftylink> only to return home with no glory

07:42 <dominikh> some have tried to test plugins. nobody really tries to add tests for Cinch itself, but the two suffer from similar issues.

07:42 <dominikh> if there'll ever be a Cinch 3, it'll have tests ;)

07:51 <dominikh> I'll finalise the patch after I got some sleep. nn.

08:50 <leftylink> hmm I wonder if http://www.irc.org/tech_docs/draft-brocklesby-irc-isupport-03.txt is the latest document on isupport. even if it is though ircds are still going above and beyond... because I notice that that STATUSMSG spec only specifies NOTICE and says nothing of PRIVMSG to @#channel . I wonder if that actually matters in practice though

08:51 <leftylink> (meaning, is there any ircd that advertises STATUSMSG and then supports NOTICE... and then doesn't support PRIVMSG)

08:52 <leftylink> not in the ones I've come across, but small sample size from me. not something I'm going to think too hard about though

19:21 <dominikh> leftylink: yeah, some will probably only permit it with NOTICE. but that's not really a problem for Cinch, we'll just support it for both.