<maetthew>
I'm trying to match messages that sometimes is colour coded and sometimes isn't. I've managed to match it when it isn't colour coded but when it is I cannot match it.
<catepillar>
no, i was doing something a little different with that... but you can do that
<catepillar>
the problem is that the color code comes BEFORE the !command that most people do
<catepillar>
so bots don't see the !command as it fails the regex
<maetthew>
hmm yeah
<maetthew>
that is true
<maetthew>
i have no idea how to go about this. this was more complex than i thought it would be
<catepillar>
made worse by the fact that colors aren't standardized
<catepillar>
though most clients *seem* to follow the same the pattern
<maetthew>
well isn't it just a problem of which pattern Cinch follows?
<catepillar>
no, its a problem of what the client outputs
<catepillar>
cinch is reading in what other clients throw out
<catepillar>
the servers are passing on the messages exactly as the clients send them out in most cases
<catepillar>
so other clients (cinch counts as a client) has to read in those messages
<maetthew>
oh ofc
<catepillar>
the one that killed me was the non-breaking space
<catepillar>
its whitespace that doesn't get counted as whitespace
<catepillar>
you see a space
<catepillar>
but if you run a regex with \S, it picks it up as a character
<catepillar>
and html uses which converts to a non-breaking space
<catepillar>
quirk that messes up code if you dont know what to look for
Lemtzas has quit [Read error: Connection reset by peer]
Lemtzas has joined #cinch
v0n has quit [Read error: Connection reset by peer]
Avogadro is now known as cout
<dominikh>
filtering colors etc from messages before applying patterns has been on the list for a while, but problem is, some sequences of color codes cannot be removed reliably without messing up the message
postmodern has joined #cinch
<catepillar>
filter for colors is by far the hardest thing I have done with cinch
<catepillar>
as in, it took me ages to figure out why it wasn't doing what i wanted. then i just decided taht if you wanted to use colors, you didn't want to use my bot.
<dominikh>
catepillar: hehe. quite frankly, I don't see why you would use colors in commands, anyway. and for all the generic kind of matching (urls, words etc), colors shouldn't matter much
<dominikh>
unless you're some weirdo who types in rainbow colors...
<catepillar>
!meaning this wont work
<catepillar>
!meaning but this will
<dominikh>
it won't, cause we don't allow colors in here ;)
<catepillar>
lol
<dominikh>
but I see your point
<dominikh>
but again, who the heck uses colors there?
<catepillar>
I have this fun script ;)
<catepillar>
great for grabbing attention. not sure it does much else.
<catepillar>
can't really read it at all
<dominikh>
heh
<dominikh>
the only times I ever allow colors in channels is when the bot needs them; and in that case I still boot people who abuse that ;)
<catepillar>
does this channel actually strip colors?
<dominikh>
it's +c, so yep
<dominikh>
and freenode strips colors in case of +c
<catepillar>
ahh
<catepillar>
see, that's not a standard :s
<dominikh>
frankly I'm happy for it. better than dropping the message
<catepillar>
yea, it is
<dominikh>
this way, I don't need to add filtering for outgoing messages in cinch, but can just say "use a sane network"
v0n has joined #cinch
<catepillar>
well, i added colorized output for my bot
<catepillar>
on stuff that isn't a direct reply
<catepillar>
cause there is a channel where it is just spitting out information
<catepillar>
necessary information
<catepillar>
but it was hard to see actual chat in the mess
<dominikh>
heh
<catepillar>
so i bowed to the pressure and set a color for it
<dominikh>
Cinchy has formatting, too. mostly just bold though iirc. there's not much wrong with using colors for bots, the problem is that it allows everyone else to use colors, too
<catepillar>
bold is useful
<catepillar>
underline occasionally
<catepillar>
colors are mostly worthless
<catepillar>
colors are annoying cause there are people (like me) with dark backgrounds
<catepillar>
while the majority have light backgrounds
<dominikh>
that's when you also set the bg color of the message and make it look really horrible
<catepillar>
so getting something visible with both is tough, unless you let the client decide its defaults
<catepillar>
most of the colors for backgrounds are bright
<catepillar>
and none of the colors are actually standardized
<catepillar>
so one person's blue might be another's dark blue, might be another's light blue
<catepillar>
it's a mess
<dominikh>
and I feel sorry for people with light backgrounds ;)
<catepillar>
i dunno why people like light themed stuff
<catepillar>
it hurts to look at
caitlinface is now known as caitlinnotacylon
v0n has quit [Ping timeout: 276 seconds]
caitlinnotacylon is now known as caitlinface
v0n has joined #cinch
v0n has quit [Read error: Connection reset by peer]
v0n has joined #cinch
v0n has quit [Ping timeout: 240 seconds]
Nowaker has quit [Ping timeout: 248 seconds]
Nowaker has joined #cinch
<lagweezle>
catepillar, dominikh: light themes are a sign of a troubled mind ;)
<dominikh>
heh
jhaals has joined #cinch
jhaals has quit [Ping timeout: 276 seconds]
jhaals has joined #cinch
robotmay has joined #cinch
jhaals has quit []
jhaals has joined #cinch
robotmay has quit [Ping timeout: 246 seconds]
jhaals has quit [Ping timeout: 260 seconds]
jhaals has joined #cinch
<maetthew>
this colouring is tearing my brains apart
<maetthew>
-s
caitlinface is now known as bananaface
bananaface is now known as caitlinface
kith has quit [Read error: Connection reset by peer]
kith has joined #cinch
<maetthew>
catepillar: /\x03\d{1,2}(?:,\d{1,2})?/
<maetthew>
will escape colours
<maetthew>
it seems
<catepillar>
yea
<catepillar>
and there is a trailing \x0f or \x0F
<catepillar>
/\x03\d{1,2}(?:,\d{1,2})?(.*)\x0F?/
<catepillar>
but that still ONLY works if the entire message is colored
<catepillar>
which is obnoxious
<catepillar>
might be better to just do subs
<maetthew>
well the messages i'm trying to parse are all outputted by other bots
<maetthew>
so they always have the same format
<maetthew>
colours can differ though
<catepillar>
right
<catepillar>
im just saying it might be easier to do a gsub than an actual match
<catepillar>
here is an example of what i was talking about where things are getting loaded twice
<dominikh>
catepillar: I'll look at it later today, busy right now
<catepillar>
take your time, its not pressing
necronian has quit [Quit: I am Quitting.]
necronian has joined #cinch
<dominikh>
catepillar: okay, what am I looking for
<dominikh>
catepillar: because in that log, I see it unloading once properly, and loading once properly
Rennex has joined #cinch
<Rennex>
hey. do you know if there's some usable cinch plugin that implements a layer that recognises users? As in based on a hostmask for weak identification and passwords for stronger ident. I'd like to restrict some commands to trusted users only, and a hard-coded nick just won't suffice :)
<dominikh>
Rennex: there's one that relies on NickServ (or Q on quakenet, K on KreyNet) for authentication.
<waxjar>
Rennex, as it happens i've been working on a cinch-authentication gem the last few days
<Rennex>
oh, cool
<waxjar>
if you like i can push to github what i have now
<Rennex>
dominikh: that might be worth looking at as an example, but i'll be needing it to work without a nickserv...
<Rennex>
waxjar: i'd be interested to take a look.
<waxjar>
haven't implemented passwords yet, though
<dominikh>
it's a nice foundation for other kinds of authentication, too. but yeah, being able to rely on nickserv made it a lot easier
<dominikh>
and technically that code right there might have a security issue, meh
<dominikh>
yup
<Rennex>
interesting stuff, both things. They also seem pretty complex, but i'm quite new to cinch so...
<waxjar>
I added a wiki page that should make things a bit clearer
bean_ has joined #cinch
bean_ has quit [Max SendQ exceeded]
bean_ has joined #cinch
lagweezle has quit [Quit: No. No! Oh god, no! Not again! NOOOOooooo!]
robotmay has joined #cinch
Uranio has joined #cinch
<Uranio>
as ALL the IRC command are events, PING could be also and event really?
<dominikh>
sure
<catepillar>
dominikh: it loads once, but it loads all the handlers twice
<dominikh>
catepillar: the log doesn't show that though
<catepillar>
am i misreading that?
<dominikh>
catepillar: yup. one is the plugin layer, one is the raw handler layer
<dominikh>
plugins are implemented via handlers
<catepillar>
ahh
<dominikh>
so those messages are duplicated
<catepillar>
ok
<dominikh>
catepillar: are you actually seeing handlers being executed twice, or were you just confused by log output?
jhaals has quit []
<catepillar>
im seeing it happen twice for that plugin
<catepillar>
and only that plugin
<catepillar>
11:37 <@catepillar> !say #CLEMENTINE test
<catepillar>
11:37 <+CLEMENTINE> test
<catepillar>
11:37 <+CLEMENTINE> test
<dominikh>
catepillar: actually, before loading the plugin again, have you made sure that !say wouldn't trigger anymore?
<catepillar>
yep
<dominikh>
also, what version of cinch are you using
<catepillar>
cinch (2.0.3
<dominikh>
well, one thing I'm quite certain about is that if there's only one "registering handler" message, only one has been registered, so any duplication in output should stem from the plugin itself
<dominikh>
catepillar: is the code public?
<catepillar>
nope
<catepillar>
but im creating a pastebin with it
<catepillar>
nothing terribly secret (or profound) about this code