All times are UTC.
00:03:34 <-- clokep_work has quit (Ping timeout: 121 seconds) 00:03:47 --> clokep has joined #instantbird 00:03:47 * ChanServ sets mode +o clokep 00:05:07 --> Alex1 has joined #instantbird 00:05:31 <-- Bollebib1 has quit (Ping timeout: 121 seconds) 00:19:59 <-- clokep has quit (Ping timeout: 121 seconds) 00:42:52 <-- chrisccoulson has quit (Ping timeout: 121 seconds) 00:46:37 --> mpmc has joined #instantbird 01:08:11 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 02:09:49 <-- EionRobb has quit (Ping timeout: 121 seconds) 02:10:01 --> EionRobb has joined #instantbird 03:16:10 <-- bgmCoder has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 04:29:50 <instant-buildbot> build #822 of linux64-nightly-default is complete: Failure [4failed shell_6] Build details are at http://buildbot.instantbird.org/builders/linux64-nightly-default/builds/822 05:24:55 <-- EionRobb has quit (Quit: Leaving.) 05:36:11 --> Bollebib has joined #instantbird 05:44:30 --> bogdan_maris has joined #instantbird 06:44:15 --> chrisccoulson has joined #instantbird 08:17:57 --> gerard-majax has joined #instantbird 08:18:13 <-- Bollebib has quit (Ping timeout: 121 seconds) 08:19:29 --> Bollebib has joined #instantbird 08:33:41 <-- gerard-majax has quit (Connection closed) 08:33:55 --> gerard-majax has joined #instantbird 08:39:42 --> EionRobb has joined #instantbird 08:40:23 <-- gerard-majax has quit (Ping timeout: 121 seconds) 08:42:42 --> gerard-majax has joined #instantbird 08:54:28 --> instantbot has joined #instantbird 08:54:28 topic changed by belew.mozilla.org to "Ask about Instantbird (http://instantbird.com) here! :-) | Last version was Instantbird 1.5 | Nightlies: http://nightly.instantbird.im (at your own risk) | News: http://blog.instantbird.org | IRC logs: http://log.bezut.info | Pastebin: http://pastebin.instantbird.org | Bugs: https://bugzilla.mozilla.org" 08:54:28 * ChanServ sets mode +v instantbot 08:56:58 <-- chrisccoulson has quit (Ping timeout: 121 seconds) 08:58:26 --> chrisccoulson has joined #instantbird 09:11:27 <-- gerard-majax has quit (Ping timeout: 121 seconds) 09:13:33 --> gerard-majax has joined #instantbird 09:17:02 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 09:19:46 <-- gerard-majax has quit (Ping timeout: 121 seconds) 09:44:16 --> gerard-majax has joined #instantbird 10:08:05 <-- Alex1 has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 10:10:00 <-- Bollebib has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 10:10:23 --> Bollebib has joined #instantbird 10:31:49 --> mpmc has joined #instantbird 10:31:55 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 10:33:59 --> flo-retina has joined #instantbird 10:33:59 * ChanServ sets mode +qo flo-retina flo-retina 10:53:32 <-- EionRobb has quit (Connection closed) 10:55:22 --> EionRobb has joined #instantbird 11:15:08 <freaktechnik> hmm, it'd be nice if twitter autocompleted usernames to @username: instead of username: 11:59:21 <flo-retina> freaktechnik: there's some code related to that, but apparently it's only triggered when double clicking a message to reply, not when tab completing. 12:01:30 --> mpmc has joined #instantbird 12:03:34 <freaktechnik> hmm, might look at it once I get a build that works 12:04:41 <freaktechnik> though I'm not too optimistic about that, since it seems m-c is busted on linux 12:46:31 --> clokep_work has joined #instantbird 12:46:31 * ChanServ sets mode +o clokep_work 13:31:43 --> bgmCoder has joined #instantbird 13:36:09 --> pachuco has joined #instantbird 13:45:15 <-- pachuco has quit (Quit: http://www.mibbit.com ajax IRC Client) 14:57:35 <freaktechnik> clokep_work: is there a bug for the ircv3 server-time cap? 14:57:49 <clokep_work> freaktechnik: I don't think I looked into that yet, no. 14:58:06 <freaktechnik> okay, I'll open one then 14:58:11 <clokep_work> :) 14:58:14 <clokep_work> What's that one do again? 14:58:18 <freaktechnik> want to get rid of my timestamps in the ZNC buffer, and have some time to spare 14:58:20 <clokep_work> (I can look it up...) 14:58:24 <freaktechnik> it gives the server timestamp 14:58:28 <clokep_work> Ah! Yeah that one is awesome. :0 14:58:45 <freaktechnik> and it should be pretty straight forward 14:58:48 <clokep_work> Yeah. 14:58:59 <clokep_work> I was goign to sit down and do that, then realized that moznet doesn't support it yet. :( 14:59:03 <clokep_work> http://ircv3.net/specs/extensions/server-time-3.2.html 14:59:18 <freaktechnik> I'll implement it like the spec says, so it will always prefer the tag, even if the cap isn't explicitly requested, since that seems easier to do. 15:02:38 <instantbot> New Chat Core - IRC bug 1302447 filed by martin@humanoids.be. 15:02:40 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1302447 enh, --, ---, nobody, NEW, Implement IRCv3.2 server-time capability 15:03:01 <clokep_work> Right...I don't really see why you'd disable it if you received it? 15:04:52 <freaktechnik> huh? No, I meant making the tag parsing independent of the actual capability negotiation. 15:06:07 <clokep_work> That's what I'm trying to say. 15:06:09 <clokep_work> :) 15:06:25 <clokep_work> I mean if we get the tag, we should just parse it. 15:06:29 <clokep_work> Not track state of if it's 'enabled' or not. 15:07:05 <freaktechnik> yeah. Btw. can I use the normal cap thing where you "remove" it once you got it here? I still don't fully understand what "removing" a CAP does. 15:10:50 <clokep_work> Umm...can you gimme a link? 15:10:51 <clokep_work> :-D 15:12:20 <clokep_work> freaktechnik: Ah, so if you expect a response from your REQ request you want to add addCAP('server-time') and then when you get teh response, do removeCAP('server-time') 15:12:30 <clokep_work> It allows for multi-message negotiation during the CAP period. 15:12:44 <freaktechnik> oh, I see. Else you just send the raw CAP REQ? 15:12:55 <freaktechnik> or just immediately remove it? 15:13:10 <clokep_work> Such that other evented code doesn't run during the CAP phase. 15:13:20 <clokep_work> Umm...you have to send it no matter what. 15:14:04 <clokep_work> https://dxr.mozilla.org/comm-central/source/chat/protocols/irc/ircSASL.jsm#133-143 15:17:28 <-- bogdan_maris has quit (Connection closed) 15:17:55 <freaktechnik> so I'd just skip the aknowledgment and just CAP REQ in the handler and return true. 15:18:43 <freaktechnik> no need for addCAP. 15:37:00 <freaktechnik> clokep_work: hmm, so I have to pass the timestamp to writeMessage or prepareForDisplaying somehow. The best way I know of would be to add it to the third argument (the one that holds the direction and system flags). So I'd have to do that everywhere were writeMessage is invoked :S 15:40:03 <freaktechnik> I guess generalizing the local writeMessage from ircBase would be in order? https://dxr.mozilla.org/comm-central/source/chat/protocols/irc/ircBase.jsm#79-85 15:50:58 <clokep_work> freaktechnik: Hmm...you'll probably want to generalize the local one, yes. 15:51:06 <clokep_work> And I think you might need to make it a writeable property in the IDL too. 15:51:13 <freaktechnik> time is writeable 15:51:30 <freaktechnik> ircProtoThing currently initializes it to Math.floor(new Date() / 1000) 15:51:37 <freaktechnik> (and XMPP alread modifies timestamps) 15:52:17 <freaktechnik> Hmm, I'd also have to adjust the CTCP handlers, right? 15:54:58 <clokep_work> Why? 15:58:53 <-- gerard-majax has quit (Ping timeout: 121 seconds) 16:04:35 <clokep_work> freaktechnik: Where do the CTCP handlers deal with time? 16:05:00 <freaktechnik> Doesn't /me get cut off from the code path in ircBase? 16:07:49 <clokep_work> "the code path"? 16:07:51 <clokep_work> The code path of what? 16:07:57 <clokep_work> Displaying messages? 16:07:59 <clokep_work> Possible.. 16:08:02 <clokep_work> Possibly. 16:08:17 <clokep_work> Hopefully they use the same method eventually though. 16:17:10 <freaktechnik> well, they have to use writeMessage on the conversation... 16:17:15 <freaktechnik> but yeah https://dxr.mozilla.org/comm-central/source/chat/protocols/irc/ircCTCP.jsm#123-126 16:17:43 <freaktechnik> and there's some system messages to, apparently 16:20:58 <freaktechnik> oh, all the mode changes could have server times too >_> 16:21:45 <clokep_work> :( 16:22:03 <clokep_work> freaktechnik: I wonder if we could pass in the message into writeMessage (optionally) and try to do the property lookup inside of there? 16:22:27 <freaktechnik> I'd say passing tags would be enough, though that'd mean expanding the imIConversation :S 16:23:00 <freaktechnik> oh wait, it is unwrapped, since it's always called on this 16:23:07 <freaktechnik> so I guess it wouldn't affect XPCOM 16:23:08 <clokep_work> Yes. 16:24:46 <freaktechnik> that sounds way simple, though I'd still have to modify about every call site in the handlers. But it would keep the server time stuff out of the jsms, and maybe even out of irc.js 16:25:10 <freaktechnik> (though I'm not sure how far it makes sense to keep it out of irc.js unless we want to add ircMessageTagHandlers) 16:25:39 <freaktechnik> (I'd use those with my twitch protocol, btw, since I have to right now do a lot of funny parsing and passing around of the tag contents) 16:27:17 <clokep_work> Oh! That's an interesting idea. 16:27:38 <clokep_work> I wonder how that would look as an API... what would be the inputs and outputs? 16:28:02 <freaktechnik> Input tags + prplIMessage, returns a modified prplIMessage 16:28:25 <freaktechnik> and then the whole normal handler stuff, I guess, with prios and success states. 16:28:31 <freaktechnik> (so it doesn't actually return the message) 16:29:01 <freaktechnik> (or it could optionally return it, just not a falsy value if it was successfull) 16:30:02 <clokep_work> Wouldn't we need to then pass the prplIMessage into all the other handlers for modification? 16:30:35 <freaktechnik> well, prplIMessage is an object, so you don't have to return it and can just modify on it. 16:30:46 <freaktechnik> hmm, there's also http://ircv3.net/specs/core/message-tags-3.3.html now... 16:31:53 <freaktechnik> which - if there were features based on them eventually, would warrant such a system even more. 16:32:14 <clokep_work> I'm not sure I'm followiing how the API would work though. 16:32:40 --> gerard-majax has joined #instantbird 16:32:51 <clokep_work> I think it also assumes there's only a single prplIMessage that is the outcome of handling an incoming message? 16:33:01 <freaktechnik> hmm, yes. 16:33:13 <freaktechnik> I don't think a tag on a single message should have effects that create another one? 16:33:31 <freaktechnik> in any case you could just this.writeMessage for new messages, though that might have ordering issues, I guess? 16:33:39 <freaktechnik> oh wait, I know of a case where that would be the case. 16:34:01 <freaktechnik> Twitch has "USERNOTICE"s, which have a NOTICE from a specific user but a system message in the tags. 16:34:23 <freaktechnik> though the generated system message does not have any tags that aren't handled there. 16:34:54 <freaktechnik> I wonder if tag handlers would have to be command specific. 16:35:24 <freaktechnik> (as in, if that is ever a requirement) 16:35:30 <clokep_work> That's doable, if it's necessary. 16:36:24 <freaktechnik> I know that it's doable, but I'm wondering if it would be necessary. Since that would IMO be bad practice, though I don't think for example message-tags would prohibit such a thing 16:36:35 <freaktechnik> so a handler should at least know what command it is working on. 16:43:41 <freaktechnik> Hmm, being able to generate multiple messages would only be an issue when the message would have to appear after the current one, right?= 16:43:55 <freaktechnik> since callcing this.writeMessage would queue it before the currently handled message. 16:45:55 <-- gerard-majax has quit (Ping timeout: 121 seconds) 16:49:32 <clokep_work> Umm...yeah, I think so. 16:50:21 <clokep_work> There's also two things that I'm getting confused about which are "messages (aka text aka prplIMessage) displayed to our user" and "IRC message sent back to the server" 16:50:31 <clokep_work> And theoretially an incoming message can have multiple of those actions of both types. 16:55:29 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 16:55:37 --> gerard-majax has joined #instantbird 16:55:59 <-- bgmCoder has quit (Ping timeout: 121 seconds) 16:58:48 <freaktechnik> sure, though I don't think that should change the return values, since the resulting incoming messages should all be stripped of the relevant tags, and ordering can be achieved based on what is not returned, I guess. Outgoing is not an issue to begin with. 16:59:05 <freaktechnik> alternatively the handlers would need a way to generate new prplIMessages that is not calling writeMessage. 16:59:11 <freaktechnik> (for incoming messages) 17:00:34 <freaktechnik> hmm, another thought. There's tag handlers that would want to be run first or last to apply their modifications, though that's not what I'd expect the normal priority attribute to do. 17:02:01 <freaktechnik> I guess a lower priority set of handlers would get called later on in the process, but that'd mean that you go through handlers then tags and save which tags you're done with instead of going through tags until you have a handler that returns true. 17:20:23 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 17:20:41 <clokep_work> The priority on handlers is meant for ordering, yes. 17:20:50 <clokep_work> Not sure how it would interact with it for tags though. 17:21:05 <freaktechnik> well it's meant for ordering on the same item 17:21:13 <freaktechnik> as in, the same tag. 17:21:40 <-- gerard-majax has quit (Ping timeout: 121 seconds) 17:22:02 <clokep_work> Yes. 17:22:38 --> flo-retina has joined #instantbird 17:22:38 * ChanServ sets mode +qo flo-retina flo-retina 17:22:50 <clokep_work> freaktechnik: Maybe like https://dxr.mozilla.org/comm-central/source/chat/protocols/irc/ircCTCP.jsm#49-109? 17:25:21 --> gerard-majax has joined #instantbird 17:25:46 <freaktechnik> I guess CTCP handlers kind of work similar. 17:26:48 <freaktechnik> hmm, so the tag handlers would be before the actual command handlers? 17:27:02 <freaktechnik> but then you don't have the prplIMessage. 17:42:45 <-- gerard-majax has quit (Ping timeout: 121 seconds) 17:49:23 <freaktechnik> clokep_work: should I open an extra bug for ircMessageTagHandlers on which server-time will depend on? 17:51:51 <clokep_work> freaktechnik: My point is that you *never* have a prplImessage... 17:52:02 <clokep_work> freaktechnik: You can do it all in there, probably as separate patches? 17:52:15 <freaktechnik> okay, that works for me. 17:52:22 <freaktechnik> I'm writing up an etherpad with what it would do. 17:52:42 <freaktechnik> So there would be some object the handlers work on that would then have to get mashed back into whatever writeMessage is doing? 17:52:59 <freaktechnik> or would run before command handlers, in which case the results might have to be carried over somehow? 17:54:00 <freaktechnik> https://public.etherpad-mozilla.org/p/irc-tag-handlers 18:08:44 <clokep_work> Yeah something like that... 18:08:55 <clokep_work> Maybe they can return something and then let them be modified later on? 18:08:57 <clokep_work> I'm not sure... 18:09:48 <freaktechnik> you mean their return value says when to apply the changes? 18:16:35 <freaktechnik> hmm, a tag handler would only need the individual value of a tag, since everything else is a message handler...? I can certainly imagine cases where there are dependencies... 18:17:21 <freaktechnik> (like translatable notices, where you can have arguments as tags, though depending on the structure you might want an extra handler for the argument tags) 18:17:32 <freaktechnik> but what if there are multiple argument tags. 18:19:13 <freaktechnik> -> @msg-id=auth-status;status-id=0;status-change=no a@example.com SOMECOMMAND 18:21:36 <freaktechnik> though I'd argue that should be done via a handler for the command with high priority 18:24:23 <freaktechnik> (you can modify the ircMessage and return false to chain etc.) 18:34:26 <freaktechnik> hmm, does https://dxr.mozilla.org/comm-central/source/chat/protocols/irc/ircCTCP.jsm#24 copy the ircMessage? That's not how I learned objects behave. 18:38:28 --> bgmCoder has joined #instantbird 18:42:07 <clokep_work> freaktechnik: No it adds to the message. 18:42:22 <freaktechnik> well, yes. But it then overwrites it in the next iteration? 18:42:32 <clokep_work> Uhhhh, probably. 18:43:27 <freaktechnik> so luckily nobody ever tried multiple CTCP commands in one message? I see. 18:45:37 <clokep_work> I'm confused why you think that won't work. 18:45:48 <clokep_work> I don't think clients *actually* do that, by the way. 18:45:51 <clokep_work> But it *should* work fine. 18:46:48 <clokep_work> freaktechnik: https://dxr.mozilla.org/comm-central/source/chat/protocols/irc/ircCTCP.jsm#71-79 18:47:12 <clokep_work> Oh...hmm....I see what you're saying. you're saying it's just pushign the same object over and over? 18:47:26 <freaktechnik> yes 18:47:28 <clokep_work> So it's actually just going to be an array of length <however many CTCP messages there are> but they'll all be the same? 18:47:47 <freaktechnik> you could as well just .fill(new CTCPMessage) an array inited to the count of matches... 18:48:15 <freaktechnik> which is count of \x01 divided by two 18:48:40 <freaktechnik> but yes, that's what I'm saying. 18:52:37 <clokep_work> Yeah looks like you found a bug. 18:52:40 <clokep_work> Congrats! :-D 18:52:46 <clokep_work> Have I mentioned that I had JavaScripts object model? 18:53:08 <freaktechnik> is that a "hate"? 18:53:17 <clokep_work> Yes. 18:53:19 <clokep_work> I need to sleep more. 18:53:23 <freaktechnik> no, you haven't yet. 18:53:54 <freaktechnik> at least cloning is simple compared to some other languages. 18:54:16 <freaktechnik> (and ircMessages don't have a prototype, which makes it even easier) 18:55:55 <clokep_work> Yep! 18:57:25 <clokep_work> I wonder if CAP messages do the same thing... 18:57:49 <clokep_work> freaktechnik: So what's your thought though? That it makes sense to parse the full message out and have all the information available to anyone who wants to deal w/ it? 18:59:21 <freaktechnik> All tags on messages that I've seen so far apply after any command handler, so it makes sense for me for them to happen after that. And then tags deal with a range of things, though mostly the four properties I listed in the etherpad (content, author, color, timestamp) 18:59:30 <freaktechnik> (whereas color is actually not really a thing) 18:59:46 <freaktechnik> but I could imagine other things, like user avatars 18:59:56 <freaktechnik> especially with client message tags. 19:00:07 <clokep_work> Right. Is there a list or do I need to just check ircv3 + 47 other places? 19:00:18 <freaktechnik> there's no list of what tags can affect. 19:00:34 <freaktechnik> and that's why I think it makes the most sense to just pass the prplIMessage and give the conversation as this. 19:00:47 <freaktechnik> hmm, or does the prplIMessage have a _conversation or something? 19:00:55 <freaktechnik> because then the prplIMessage could be the this. 19:02:03 <freaktechnik> yeah, the jsPRotoHelper one has _conversation 19:02:11 <freaktechnik> so I guess in theory the prplIMessage could even be the this 19:03:09 <freaktechnik> hmm, though it may only be set when it is actually added to the conv? so that wouldn't work. 19:03:21 <clokep_work> I guess it doesn't make sense for a tag to do anything except for deal w/ the current message. 19:03:45 <clokep_work> You probably want the account to be |this| just to keep the API simlar. 19:04:06 <freaktechnik> oh, right, account 19:04:16 <freaktechnik> well, tags may want to change stuff within the account too 19:04:30 <freaktechnik> like save things about yourself or similar 19:04:44 <freaktechnik> (twitch has a command that tells you what emotes you can use and what your display name is etc.) 19:05:03 <freaktechnik> though I guess again, this should be a command handler and not a tag handler. 19:09:48 <clokep_work> Right. :) 19:11:38 <clokep_work> Would it help to code up one or two places where we'd need to handle timestamp manually? 19:11:50 <clokep_work> And see if that helps us understand what data it needs and what it needs to pass through? 19:12:19 <freaktechnik> well, the timestamp tag needs exactly two things: the value of the timestamp tag and then be able to set that/pass that through. 19:12:54 <freaktechnik> (the tag is called "time") 19:15:24 <freaktechnik> Hmm, okay, I unified the API to fit better with how the handler APIs work currently, by adding a wrapper object that holds the value for the tag and the tag name. 19:15:49 <freaktechnik> I'm not sure anymore what the command name would be needed for for something that shouldn't be happening in a command handler, resp. couldn't happen in a command handler. 19:16:00 <freaktechnik> I don't think this API should solve command-specific tags. 19:16:50 <freaktechnik> is there a reason to also have the handlers run on messages that don't get printed to the user though? 19:19:03 <clokep_work> I don't think so? 19:19:14 <clokep_work> And yeah, ignore command-specific tags unless we need it. 19:19:35 <clokep_work> How are you using tags already in your code? 19:19:43 <clokep_work> I know you implemented the parsing, so you must be using them somewhere! 19:19:48 <freaktechnik> hmm, I'm just wondering if it's worth trying to inherit from a prplMessage instead of just making it a property on the custom message. 19:20:01 <freaktechnik> I'm currently doing the spaghettiest of spaghetti 19:20:25 <clokep_work> Heh. :) 19:20:30 <freaktechnik> Essentially I have a custom handler for every command that has relevant tags with a higher prio than the built in ones and they set the relevant tag values in relevant places. 19:20:31 <clokep_work> So making it so you don't have to do that would be good! 19:20:42 <freaktechnik> Which are the third argument of writeMessage if they are message specific 19:20:51 <clokep_work> Right. 19:20:52 <freaktechnik> else they go somewhere into the account, conversation or a buddy 19:21:41 <freaktechnik> yes, especially since I had to rebuild PRIVMSG and ACTION just to get the tag values. 19:21:57 <clokep_work> I'm trying to find it in... https://github.com/freaktechnik/twitch-provider/blob/master/lib/twitch/handlers.js? 19:22:09 <freaktechnik> yeah, it's all over that 19:22:25 <freaktechnik> essentially all the message.tags is reading the tags and doing something with it 19:22:34 <freaktechnik> a big part of them wouldn't be a tag handler. 19:23:10 <freaktechnik> but privmsg, whisper and the CTCP handlers would not be needed at least. 19:23:52 <freaktechnik> the other ones all generate some kind of system message. 19:24:30 <freaktechnik> (well, except for the JOIN PART ones which I actually have to check if I still need them) 19:27:26 <clokep_work> Would it make sense to run the tags *first* and have them set a list of "display flags" on the ircMessage. 19:27:44 <clokep_work> And then places that call writeMessage can pass those + their own flags into writeMessage? 19:28:36 <freaktechnik> It doesn't matter for most of them, though passing it on means that you then also have to handle the new flags in prepareForDisplaying 19:29:02 <clokep_work> Where? 19:29:28 <freaktechnik> in the conversation 19:29:41 <freaktechnik> since they might modify stuff that should be set on the prplIMessage. 19:29:48 <freaktechnik> (and does not exist previously) 19:29:57 <freaktechnik> oh wait 19:30:05 <freaktechnik> I'm not remembering what writeMessage does >_> 19:30:13 <clokep_work> Can you point to the code for me? 19:30:49 <freaktechnik> the third argument of writeMessage gets merged into the prplIMessage in https://dxr.mozilla.org/comm-central/source/chat/modules/jsProtoHelper.jsm#511 which I forgot about 19:31:34 <freaktechnik> so a handler would return an object that then gets merged together from all handlers and passed on to the command handler? 19:32:27 <freaktechnik> though how would they modify message content? 19:32:31 <freaktechnik> magic property on that object? 19:33:12 <freaktechnik> because the emotes tag gets applied in the end, as it replaces certain text sequences with emotes in the message. 19:35:02 <clokep_work> That's kind of what I was thinking, yeah. 19:36:00 <freaktechnik> so the argument would be an ircMessage (with the tagName to look for set) 19:36:14 <freaktechnik> (mostly to be able to re-use the handler infrastructure) 19:36:21 <clokep_work> I think so... 19:36:30 <freaktechnik> dswait, that wouldn't be possible, since the return value has to be respected. 19:38:04 <clokep_work> Oh I didn't realize they need to replace some content to...hm.... 19:38:13 <clokep_work> Now I'm confused. :-D 19:41:40 <freaktechnik> hmm, I still think implementing as running it after writeMessage is simpler. 19:43:30 <freaktechnik> though that leaves the problem of how to get tags in there. 19:44:02 <freaktechnik> which might be just as complicated. Hrm. 19:45:17 <clokep_work> Will all tags be processed as part of message display? 19:45:29 <clokep_work> We could pass the entire prplMessage (or just the tags) into writeMessage and do the logic there? 19:45:44 <freaktechnik> well, write message creates the prplIMessage. 19:46:09 <freaktechnik> which then gets processed in prepareForSending 19:46:25 <freaktechnik> the problem is, that at that point only message content, sender and properies for prplIMessage are left. 19:47:10 <clokep_work> Right...I'm suggesting passing more information into writeMessage. 19:47:31 <freaktechnik> yeah, which'd mean updating every writeMessage that could have tags... 19:47:43 * clokep_work wonders what calls prepareForSending. 19:47:49 <freaktechnik> uh, an observer 19:48:05 <freaktechnik> because setting the conversation on a prplIMessage emits a new-text notif 19:51:46 <freaktechnik> (-> https://dxr.mozilla.org/comm-central/source/chat/modules/jsProtoHelper.jsm#418) 20:05:18 <freaktechnik> clokep_work: so that'd look something like https://gist.github.com/freaktechnik/ac12d95b408ac74c127fc8ad4aba50ee 20:07:01 <freaktechnik> and https://gist.github.com/freaktechnik/f9ba42c683551124540853eb8e749afc would be the implementation for the server time spec. 20:07:03 <clokep_work> freaktechnik: At firce glance it doesn't seem too crazy. 20:10:47 <freaktechnik> btw. shouldn't https://dxr.mozilla.org/comm-central/source/chat/modules/jsProtoHelper.jsm#389 floor? 20:10:56 <freaktechnik> at least that's how time is normally rounded. 20:11:06 <freaktechnik> but I guess that works too... 20:15:39 <clokep_work> You mean to truncate? 20:15:42 <clokep_work> Yeah it probably shouldn.t 20:15:44 <clokep_work> Should! 20:15:48 <clokep_work> It probably should! 20:16:54 <freaktechnik> that was my thought too... 20:17:25 <freaktechnik> it also explains why I've been con fused by IB timestamps in the past 20:27:34 --> satdav has joined #instantbird 20:27:42 <instantbot> New Chat Core - General bug 1302537 filed by martin@humanoids.be. 20:27:43 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1302537 min, --, ---, nobody, NEW, Default time stamp should just forget about ms 20:30:43 <instantbot> New Chat Core - IRC bug 1302538 filed by martin@humanoids.be. 20:30:45 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1302538 nor, --, ---, nobody, NEW, CTCP messages all get the same content 20:49:53 <freaktechnik> hmm, the fact that server-time uses TAI (timestamps with leap-time) timestamps makes this more complicated. 20:50:09 <freaktechnik> I guess there's always the hope that there won't be any timestamp doing that, buut 20:51:39 <freaktechnik> I guess they could just be ignored away, since the generated time stamp won't account for it in any case, but even that sounds complicated. 20:52:59 <-- clokep_work has quit (Ping timeout: 121 seconds) 20:59:42 <freaktechnik> hmm, I don't see how ISO8601 would allow for leap seconds :( 21:00:46 <freaktechnik> hm, I guess it does 21:01:06 <freaktechnik> hmm, then Date.parse is not ISO8601 compilant in gecko :( 21:02:49 <Mook_as> Date is from Java 1.0; assume everything about it is totally terrible. 21:03:39 <freaktechnik> ES5 according to MDN added ISO8601 support. 21:03:51 <freaktechnik> so I would expect it to be able to parse legal ISO8601 dates. 21:04:12 <freaktechnik> though apparently ES5 was very particular about how that support works. 21:05:09 <freaktechnik> oooh 21:05:23 <freaktechnik> I guess leap seconds don't map to a UNIX timestamp, and thus are NaN >_> 21:05:24 <freaktechnik> <_> 21:09:02 <freaktechnik> I doubt many IRC servers actually account for leap seconds, since their systems are probably UNIX timestamp-based too, so they don't even know about leap seconds... 21:18:43 --> unghost has joined #instantbird 21:30:01 <-- chrisccoulson has quit (Ping timeout: 121 seconds) 21:39:35 --> clokep_work has joined #instantbird 21:39:36 * ChanServ sets mode +o clokep_work 21:43:37 <-- clokep_work has quit (Ping timeout: 121 seconds) 21:48:59 <-- EionRobb has quit (Quit: Leaving.) 21:50:40 --> clokep_work has joined #instantbird 21:50:40 * ChanServ sets mode +o clokep_work 21:54:41 <-- clokep_work has quit (Ping timeout: 121 seconds) 22:00:36 --> clokep_work has joined #instantbird 22:00:37 * ChanServ sets mode +o clokep_work 22:04:38 <-- clokep_work has quit (Ping timeout: 121 seconds) 22:10:34 --> clokep_work has joined #instantbird 22:10:35 * ChanServ sets mode +o clokep_work 22:14:36 <-- clokep_work has quit (Ping timeout: 121 seconds) 22:20:35 --> clokep_work has joined #instantbird 22:20:35 * ChanServ sets mode +o clokep_work 22:24:36 <-- clokep_work has quit (Ping timeout: 121 seconds) 22:31:34 --> clokep_work has joined #instantbird 22:31:35 * ChanServ sets mode +o clokep_work 22:35:36 <-- clokep_work has quit (Ping timeout: 121 seconds) 23:01:31 --> clokep_work has joined #instantbird 23:01:32 * ChanServ sets mode +o clokep_work 23:05:33 <-- clokep_work has quit (Ping timeout: 121 seconds) 23:07:01 <-- unghost has quit (A TLS packet with unexpected length was received.) 23:19:43 <-- Bollebib has quit (Connection closed) 23:20:03 --> Bollebib has joined #instantbird 23:37:50 <-- satdav has quit (Quit: Leaving) 23:38:06 <-- Bollebib has quit (Ping timeout: 121 seconds) 23:39:35 --> clokep_work has joined #instantbird 23:39:36 * ChanServ sets mode +o clokep_work 23:39:41 --> EionRobb has joined #instantbird 23:43:37 <-- clokep_work has quit (Ping timeout: 121 seconds)