All times are UTC.
00:11:15 <-- Tonnes has quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725]) 00:59:52 <-- Mook_as has quit (Quit: gone) 01:23:01 <-- Suiseiseki has quit (Ping timeout) 01:24:05 --> Suiseiseki has joined #instantbird 01:24:36 --> NmN has joined #instantbird 02:22:49 <-- gpsychosis has quit (Ping timeout) 03:11:49 --> EionRobb has joined #instantbird 03:13:04 <-- Suiseiseki has quit (Ping timeout) 03:14:33 --> Suiseiseki has joined #instantbird 03:29:25 <-- EionRobb has quit (Ping timeout) 03:30:42 --> EionRobb has joined #instantbird 04:12:38 <-- EionRobb has quit (Quit: Leaving.) 04:36:05 <-- NmN has quit (Quit: Instantbird 1.1) 04:43:58 --> clokep has joined #instantbird 04:43:58 * ChanServ sets mode +o clokep 04:53:05 <-- clokep has quit (Quit: Instantbird -- http://www.instantbird.com) 05:34:17 --> NmN has joined #instantbird 06:03:08 <instant-buildbot> build #466 of macosx-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/466 06:12:24 <-- Suiseiseki has quit (Ping timeout) 06:13:53 --> Suiseiseki has joined #instantbird 06:31:40 <-- meh has quit (Ping timeout) 06:42:39 --> meh has joined #instantbird 06:45:46 --> gpsychosis has joined #instantbird 06:59:43 --> pvagner has joined #instantbird 07:03:50 <-- Suiseiseki has quit (Ping timeout) 07:04:48 --> Suiseiseki has joined #instantbird 07:25:27 <-- pvagner has quit (Ping timeout) 07:26:29 --> pvagner has joined #instantbird 07:33:36 --> Kaishi has joined #instantbird 07:36:59 <-- Kaishi has quit (Quit: Kaishi) 07:37:04 --> Kaishi has joined #instantbird 07:40:12 <-- meh has quit (Ping timeout) 07:48:24 <-- gpsychosis has quit (Quit: Instantbird 1.1) 07:59:06 --> meh has joined #instantbird 08:31:44 --> jb has joined #instantbird 08:38:40 <-- meh has quit (Quit: reboot) 08:40:43 --> meh has joined #instantbird 09:18:42 <-- flo has quit (Ping timeout) 09:21:35 <-- jb has quit (Ping timeout) 09:39:03 <-- sander85 has quit (Client exited) 09:40:28 --> sander85 has joined #instantbird 09:41:27 <-- Tomek has quit (Ping timeout) 09:44:15 --> Tomek has joined #instantbird 09:50:39 <-- meh has quit (Ping timeout) 09:58:37 --> meh has joined #instantbird 10:10:55 <-- pvagner has quit (Ping timeout) 10:19:05 <-- Even has quit (Ping timeout) 10:33:34 <-- NmN has quit (Quit: Instantbird 1.1) 10:35:11 --> flo has joined #instantbird 10:35:12 * ChanServ sets mode +qo flo flo 10:35:19 <flo> another restart required to reconnect :( 10:35:56 <flo> this is what I had in the error console when trying to disconnect the "connecting..." irc account: http://i.imgur.com/GFwxe.png 10:36:39 <flo> the libpurple accounts were stuck on "connecting..." too (they should have timeouted), but disconnecting them worked, and after than it was possible to reconnect them 10:50:35 --> EionRobb has joined #instantbird 11:32:46 <-- EionRobb has quit (Quit: Leaving.) 12:15:38 --> aleth has joined #instantbird 12:15:38 * ChanServ sets mode +h aleth 12:19:33 --> sonny has joined #instantbird 12:20:22 --> Tonnes has joined #instantbird 12:21:46 <-- sonny has quit (Quit: Instantbird -- http://www.instantbird.com) 12:24:13 --> sonny has joined #instantbird 12:26:22 <-- aleth has quit (Quit: Instantbird -- http://www.instantbird.com) 12:27:07 --> aleth has joined #instantbird 12:27:07 * ChanServ sets mode +h aleth 12:38:34 --> clokep has joined #instantbird 12:38:34 * ChanServ sets mode +o clokep 12:43:50 --> Mic has joined #instantbird 12:43:50 * ChanServ sets mode +h Mic 12:44:01 <Mic> Hi 12:44:47 <Mic> Pressing tab in the middle of an already completed nick produces garbage :( 12:47:52 <-- flo has quit (Ping timeout) 12:49:51 --> flo has joined #instantbird 12:49:51 * ChanServ sets mode +qo flo flo 12:50:05 <flo> another power outage, another restart required to reconnect IRC :( 12:50:23 <flo> Mic: what behavior would you expect in that case? 12:50:54 <flo> the current behavior seems to be mostly what I expect when pressing tab in the middle of an already full nick :-S 12:51:04 <Mic> Either nothing or resume cycling (I guess the latter is hard?) 12:51:20 <clokep> I think doing nothing is reasonable. 12:51:48 <Mic> The latter is what I tried. I had two nicks completed and noticed the first one was wrong, so I went back to it and pressed tab 12:51:59 <flo> so it would do nothing when the cursor is in the middle of a word rather than at the end of one? 12:52:09 <flo> I don't really see the benefit of adding such a special case 12:53:08 <Mic> What's the use-case for completing from the middle of a word? 12:55:12 <flo> Mic: none. 12:55:48 <flo> Mic: the user action doesn't seem to make much sense, so I don't see producing a result that doesn't make much sense either as an issue 12:56:13 <flo> but if you want to change that behavior, I guess I don't mind :) 13:01:23 <-- meh has quit (Ping timeout) 13:07:15 <-- Tomek has quit (Quit: Instantbird 1.1) 13:11:04 <-- clokep has quit (Ping timeout) 13:11:39 --> clokep has joined #instantbird 13:11:39 * ChanServ sets mode +o clokep 13:15:33 <clokep> flo: There's no way to tell an instance of Instantbird it's "offline" now, is there? 13:15:36 --> meh has joined #instantbird 13:15:44 <clokep> (I don't mean setting the status to offline, I mean tricking it to think it has no internet.) 13:20:08 <flo> clokep: set necko to offline 13:22:03 <flo> clokep: we have code to force online at http://lxr.instantbird.org/instantbird/source/instantbird/content/debug/debug.js#32 13:22:11 <flo> I'm sure you can figure out how to force offline ;) 13:22:55 <flo> but I think most of the problems I experience are when necko is online but I've no internet connection, ie it can open sockets successfully, but no response will ever be received 13:26:05 <flo> "chrome/* chrome/*/*" hmm? Isn't the second one already included in the first? 13:26:25 <clokep> Seemingly no. :( 13:26:36 <clokep> I wonder if chrome/** globing would work? 13:36:09 <clokep> :-S I'm very confused at how the output stream doesn't exist in that screenshot. 13:39:19 <flo> clokep: because of this, most likely: Error: [Exception... "Component returned failure code: 0x804b0010 (NS_ERROR_OFFLINE) [nsISocketTransportService.createTransport]" nsresult: "0x804b0010 (NS_ERROR_OFFLINE)" location: "JS frame :: resource:///modules/socket.jsm :: <TOP_LEVEL> :: line 443" data: no] 13:39:34 <flo> this error exists earlier in the error console (I noticed it at the second power outage) 13:40:14 <flo> I think it goes back to the "we should stop the auto-reconnect timers when necko's network status changes to offline, and restart them when back online" bug. 13:40:29 <clokep> Hmmm...maybe. 13:40:35 <flo> I think currently we check if the network is online before letting the user attempting to connect, but reconnect timers don't have that check 13:40:53 <flo> + there are probably several different error handling issues in socket.jsm 13:41:34 <flo> the IRC code also misbehaves, as it's clearly visible in the screenshot that it attempted to write a QUIT comment on a socket that has never been connected... 13:41:53 <clokep> Yeah, I noticed that. 13:41:59 <flo> so, probably at least 3 or 4 different bugs piling on top of each other, making the situation quite confusing 13:42:44 <clokep> Probably need a check at http://lxr.instantbird.org/instantbird/source/chat/protocols/irc/irc.js#818 13:43:24 <flo> or at http://lxr.instantbird.org/instantbird/source/chat/protocols/irc/irc.js#808 13:43:38 <clokep> Right. 13:43:42 <clokep> That probably makes more sense. 13:44:01 <flo> and if we have no socket, we should call this.gotDisconnected immediately, rather than waiting 2 seconds 13:44:09 <flo> the server will never reply anyway 13:44:41 <flo> do you have an easy way to check if the socket has actually been connected? 13:45:39 <flo> maybe we need to set a boolean member variable when onConnection is called, and delete it in gotDisconnected? 13:47:20 <flo> when does it make sense to send the QUIT command? I suspect the socket being connected isn't enough, it's probably meaningful only if there has been some dialog between the server and us on that socket, although I don't really know enough of the IRC protocol to really know :) 13:47:24 * clokep thought we had a isConnected method... 13:47:35 <flo> ah? :) 13:48:04 <clokep> Well there's "isAlive" which checks if the transport is alive (whatever that means. ;)) 13:48:34 <flo> should the sendMessage and sendRawMessage method in irc.js refuse to send anything if there's no connected socket? 13:48:53 <clokep> Yes. 13:48:53 <flo> (and by refuse, I mean complain loudly in the error console/terminal that something wrong is happening) 13:49:37 <clokep> If you're connected to the server it makes sense to send the QUIT command. 13:49:49 <clokep> Even if you haven't handshaked or anything. 13:50:06 <flo> is the isAlive check correct at http://lxr.instantbird.org/instantbird/source/chat/modules/socket.jsm#182 ? 13:50:17 <flo> ok 13:50:41 <flo> is anything using that strange reconnect method? 13:50:54 <clokep> Nothing is, I was using it in reconnect for a while. 13:51:03 <clokep> And that isAlive check looks wrong, yes. 13:51:14 * flo suggests removing the method 13:53:01 <flo> the isAlive implementation is at http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsSocketTransport2.cpp#1874 13:53:06 <flo> seems OK to call :) 13:54:01 <clokep> OK. :) 13:54:02 <clokep> Good. 13:57:46 * flo wonders if the current discussion means that JS-IRC's behavior with a flaky internet connection is going to suck significantly less in the near future :) 13:58:03 --> NmN has joined #instantbird 14:03:38 <clokep> flo: Unrelated, but I was trying to get my LJ Talk extension to work again and when I attempt to connect I get this: http://i.imgur.com/hrDDy.png does that look reasonable? Why do we just randomly disconnect? 14:06:47 <clokep> I end up in http://lxr.instantbird.org/instantbird/source/chat/protocols/xmpp/xmpp-session.jsm#202 :( 14:07:29 <clokep> Bah so it doesn't seem to be the xmpp code doing crazy things. 14:07:42 --> jb has joined #instantbird 14:08:05 <clokep> Wait...it seems to be trying to send the initial connect message a second time? 14:18:33 <clokep> Apparently that seems correct. 14:18:35 * clokep gives up for the day. 14:35:05 <flo> so it fails when starting TLS? 14:37:48 <clokep> I guess so. :( 14:38:11 <clokep> Could that be an invalid cert? 14:38:21 <flo> maybe 14:38:33 <flo> is it us or the server closing the connection? 14:38:48 <clokep> Server I think. 14:39:08 <clokep> Wel that's what the error message says. ;) 14:39:22 <flo> there's no error message in your console 14:39:36 <flo> maybe we are using a version of SSL/TLS that the server doesn't support? 14:40:44 <clokep> The error message in the account manager says it was the server. 14:40:52 <clokep> It's from the onConnectionClosed method of the socket. 14:46:51 <flo> I don't really trust the error reporting we currently have :( 14:51:02 <instantbot> New Core - IRC bug 1409 filed by clokep@gmail.com. 14:51:06 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1409 nor, --, ---, nobody, NEW, Handle (dis)connects better in IRC 14:52:46 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 14:57:24 <-- NmN has quit (Quit: Instantbird 1.1) 15:03:58 <-- SM0TVI has quit (Ping timeout) 15:12:55 --> SM0TVI has joined #instantbird 15:27:14 <-- Kaishi has quit (Quit: Kaishi) 15:36:41 <-- SM0TVI has quit (Connection reset by peer) 15:38:14 <-- jb has quit (Quit: jb) 15:38:38 --> jb has joined #instantbird 15:40:09 --> SM0TVI has joined #instantbird 15:41:25 <-- jb has quit (Ping timeout) 15:54:15 --> NmN has joined #instantbird 15:54:55 <-- SM0TVI has quit (Quit: I view things as they are, without regard to place or person; my country is the world, and my religion is to do good. -- Thomas Paine (*1737 â 1809)) 16:03:42 --> SM0TVI has joined #instantbird 16:17:34 --> Mic|web has joined #instantbird 16:57:09 --> Even has joined #instantbird 16:57:10 * ChanServ sets mode +o Even 17:06:16 <-- meh has quit (Ping timeout) 17:17:26 --> igorko has joined #instantbird 17:19:54 <Mic|web> executeSoon is something I can use instead of setTimeout( .. ,0) iirc? 17:20:26 <-- sonny has quit (Ping timeout) 17:20:35 --> meh has joined #instantbird 17:21:11 <aleth> Mic|web: yes, I think it's preferred even. 17:22:34 --> mmkmou has joined #instantbird 17:22:52 <Mic|web> Does it have exactly the same effect? Here's the setTimeout-call I found and the reason why it is there: http://lxr.instantbird.org/instantbird/source/instantbird/content/conversation.xml#1389 17:25:27 <aleth> Ah, sorry. I think what is preferred is |Services.tm.mainThread.dispatch(function, Ci.nsIEventTarget.DISPATCH_NORMAL);| 17:25:51 <aleth> That should have the same effect. 17:26:06 <Mic|web> http://lxr.instantbird.org/instantbird/source/chat/modules/imXPCOMUtils.jsm#121 ;) 17:26:22 <aleth> haha ok :) 17:26:56 <aleth> I just tried to look up executeSoon on mdn, no wonder I didn't find it... 17:29:56 --> sonny has joined #instantbird 17:32:29 <clokep> Mic|web: I think it would work fine in that situation...but I didn't write that code. :-D 17:33:18 --> EionRobb has joined #instantbird 17:33:53 <aleth> setTimeout is window-specific I believe, I'm not sure that's a relevant difference though. 17:35:05 <-- EionRobb has quit (Ping timeout) 17:35:17 <aleth> and the 0 really means at least 4ms 17:37:52 <clokep> 4ms is close enough to 0 for me. ;) 17:38:17 <aleth> clokep: Sure, but there will be a technical difference as this is enforced. 17:38:51 <clokep> executeSoon throws things onto the stack to be executed whenever there's a chance (I think) while setTimeout will actualy try to execute at a certain time. 17:39:37 <aleth> Yes, executeSoon just adds to the main thread 17:47:22 <instantbot> benediktp@ymail.com requested feedback from florian@instantbi rd.org for attachment 1411 on bug 958. 17:47:25 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=958 enh, --, ---, nobody, NEW, Show last messages (history) in new chat windows 17:47:31 <aleth> Hmm, I guess if you had a situation (not in the code above of course) where you had a lot of setTimeout(0)'s you would introduce noticeable delays 17:49:18 <Mic|web> I haven't figured out how to show the messages as context messages, though :( 17:50:13 <aleth> It's just a flag to set on each message as far as I remember. 17:50:29 <Mic|web> Setting "context = true" on each message failed with something like "not possible on wrapped object" 17:51:17 <aleth> Something more subtle then... 17:52:37 <aleth> Is it possible you just need to adjust _readcount in conversation.xml (showFirstMessages)? 17:52:39 <clokep> aleth: I don't think it's a flag on the message. 17:52:50 <clokep> Yes, I think that's how you do it. 17:53:12 <aleth> clokep: It is at some point, but I think you right in that that happens at a later stage. 17:53:49 <clokep> My point is that it's not part of the interface. :) 17:55:03 <aleth> Yes :) 17:56:30 <aleth> Mic|web: Why did you add to the conversation-loaded handler rather than _showFirstMessages? 17:56:51 <aleth> (just wondering) 17:58:31 <Mic|web> I'm not sure I understand? 17:58:46 <Mic|web> Do you mean why I didn't add my code into _showFirstMessages? 17:59:08 <aleth> Why don't you call showcontextfrom logs from showfirstmessages? 18:00:36 <-- mmkmou has quit (Ping timeout) 18:00:43 <Mic|web> hmm, it felt cleaner to call one after the one instead of chaining them 18:00:44 <aleth> Btw it's great you are adding this :) It will be really nice to have. 18:01:07 <Mic|web> I have to say that it was easier than I expected. 18:01:40 <aleth> I just asked because that way you would be able to return the number of previous messages, and not fetch any when restoring from hold 18:02:36 <aleth> s/previous messages/messages actually fetched from logs 18:03:14 <aleth> and then use the number to adjust _readcount 18:04:10 --> mmkmou has joined #instantbird 18:04:23 <-- clokep has quit (Ping timeout) 18:07:10 <aleth> ie in _showFirstMessages, add |if (!_readCount) _readCount = _showContextFromlogs()| 18:07:42 <aleth> (something like that, I haven't looked in detail) 18:08:21 <Mic|web> i.e. don't show context from logs when there are (unread) messages in this conv already? 18:08:44 <aleth> Don't show context when you are restoring from hold and there are /context/ messages already 18:08:52 <aleth> Since the point of this is to provide context? 18:09:15 <-- mmkmou has quit (Ping timeout) 18:09:21 <aleth> Uh, that sounds confusing 18:09:29 <Mic|web> I don't think that would be right. How would you explain where the messages went? 18:10:02 <aleth> You mean compared to before the conversation was put on hold? 18:10:07 <aleth> That's a good point. 18:10:37 <aleth> Maybe I was wrong to suggest that and it's better to always add them from the logs 18:11:04 <aleth> You still need to tell _readCount how many you actually managed to fetch from the logs though 18:13:31 <Mic|web> Yes, something like that. I didn't really try to understand what's going on with the previous messages of the conv. The function's name scared me away ;) 18:13:42 <aleth> This could be an easier way to do it: 18:13:46 <aleth> Keep your current code 18:14:19 <aleth> Hmm no. That's too simple as it's asynchronous. 18:14:27 <aleth> (Sorry, thinking aloud here) 18:15:22 <aleth> The point I am trying to make is that _readCount needs to be += the number of messages you fetched from the logs before the first addMsg is called 18:16:00 <aleth> Currently _showFirstMessages sets _readCount, and the way you set it up, it knows nothing about what _showContextFromLogs did 18:17:11 <aleth> And then the context messages will be displayed as context messages :) 18:19:42 <Mic|web> Would be greatif you could you add that to the bug? So we have the feedback where it belongs? 18:19:47 <Mic|web> *great if 18:20:53 <aleth> Sure 18:21:16 <Mic|web> I requested feedback from clokep and fl o already, so maybe they'll only have to confirm that (or say why they have a different opinion) 18:23:14 <Mic|web> bbl 18:24:31 <-- Mic|web has quit (Quit: http://www.mibbit.com ajax IRC Client) 18:34:15 --> mmkmou has joined #instantbird 18:36:19 <-- chrisccoulson has quit (Connection reset by peer) 18:43:20 --> Mic|web has joined #instantbird 18:46:13 --> chrisccoulson has joined #instantbird 18:47:03 <-- mmkmou has quit (Ping timeout) 18:58:49 --> mmkmou has joined #instantbird 19:05:31 <instantbot> New Instantbird (UI) bug 1410 filed by benediktp@ymail.com. 19:05:33 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1410 min, --, ---, nobody, NEW, [Tab Complete] Pressing tab while cursor is in a nickname produces garbage 19:07:42 <-- mmkmou has quit (Quit: Instantbird -- http://www.instantbird.com) 19:09:03 <-- meh has quit (Quit: I don't want to live on this planet anymore.) 19:12:16 <-- NmN has quit (Quit: Instantbird 1.1) 19:16:09 <instantbot> New Instantbird (UI) bug 1411 filed by benediktp@ymail.com. 19:16:13 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1411 enh, --, ---, nobody, NEW, Show link target in Firefox-like panels in the corners over the conversation content 19:19:11 * bear-afk is now known as bear|tablet 19:19:12 * bear|tablet is now known as bear 19:19:22 * bear is now known as bear|tablet 19:24:32 * bear|tablet is now known as bear-afk 19:33:01 --> Mnyromyr has joined #instantbird 19:33:09 --> Kaishi has joined #instantbird 19:40:56 --> wnayes has joined #instantbird 19:41:20 <Mic|web> Hello wnayes 19:41:36 <wnayes> Hello 19:43:32 <wnayes> I've been working on bug 1391 for awhile now 19:43:36 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1391 enh, --, ---, nobody, NEW, Simplify account creation wizard 19:44:17 <Mic|web> Cool, do you think you're getting along fine? 19:45:12 <wnayes> I've got a design running similar to the mockup by flo posted. 19:45:28 <wnayes> Not sure yet how to handle the localization aspect yet. 19:46:31 <Mic|web> i.e. how to make the list of networks customizable for localizers? 19:46:45 <Mic|web> *items on the list 19:47:53 <wnayes> Exactly, I don't think that would be something placed in the wizard dtd file. 19:51:26 <Mic|web> hmm, I think I'd try that for a start and request feedback on it. 19:52:58 <wnayes> Alright, some sort of splittable string would probably work. 19:53:12 <Mic|web> I'd use something like: favouriteNetwork1.protoid "prpl-aim" favouriteNetwork1.label "AOL Instant messaging network", favouriteNetwork2... 19:54:22 <Mic|web> (since you know that there's a limited number of slots (3 in flo's mockup) 19:55:34 <wnayes> Makes sense, I'll give it a try. Thanks :) 19:55:57 <Mic|web> I think reading from a properties file and filling the slots from JS might be better? 19:56:04 <Mic|web> I need to go, though. 19:56:12 <Mic|web> So have a nice day and good luck with this :) 19:56:16 <Mic|web> bye 19:56:38 <-- Mic|web has quit (Quit: http://www.mibbit.com ajax IRC Client) 20:04:48 <-- Suiseiseki has quit (Ping timeout) 20:31:55 <aleth> Mic: I left a comment on bug 958, I hope it's comprehensible. 20:32:00 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=958 enh, --, ---, nobody, NEW, Show last messages (history) in new chat windows 20:33:01 <aleth> Btw do you also see only (vertically) half of text in the statusbar displayed when the Smile addon is running, or is that a Linux-only thing? 20:35:41 --> EionRobb has joined #instantbird 20:36:09 <aleth> wnayes: If you reach a stage where you'd like feedback on your patch, you can attach a WIP to the bug and set the feedback flag :) 20:36:28 --> Suiseiseki has joined #instantbird 20:36:30 <aleth> Sounds like you're finding your way around quickly... 20:39:28 <wnayes> aleth: Thanks for the tip, hopefully I'll have something working by the end of the weekend. 20:47:00 <-- EionRobb has quit (Quit: Leaving.) 20:56:40 <-- igorko has quit (Ping timeout) 21:01:53 --> mmkmou has joined #instantbird 21:03:47 <-- mmkmou has quit (Ping timeout) 21:18:39 <-- wnayes has quit (Quit: Instantbird -- http://www.instantbird.com) 21:26:50 --> mmkmou has joined #instantbird 21:47:04 <flo> https://twitter.com/AFFogarty/status/196296508201639936 ! :-) 21:49:43 --> Mic has joined #instantbird 21:49:43 * ChanServ sets mode +h Mic 21:56:36 <aleth> :) 21:56:41 <instantbot> aletheia2@fastmail.fm requested review from florian@instantbird .org for attachment 1412 on bug 1410. 21:56:43 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1410 min, --, ---, aletheia2, ASSI, [Tab Complete] Pressing tab while cursor is in a nickname produces garbage 22:05:30 <flo> looking at that patch to add context messages 22:06:39 <flo> wouldn't getConversation().getMessages cause synchronous disk I/O? 22:08:46 <aleth> ^^ Mic 22:09:05 <Mic> Yes, I think so, but I'm pretty away atm 22:09:59 <flo> and it seems our logs are written synchronously too :( 22:10:02 <Mic> i.e. it would be cool if you could put question in the bug or at least hope not that I can answer immediately 22:11:08 <flo> Mic: I wasn't hoping an immediate answer, more thinking out loud ;) 22:11:24 <flo> Mic: sorry if that wasn't obvious :-S 22:13:32 <flo> (I think I would have included your nick if I was expecting an answer, by the way) 22:27:26 <instant-buildbot> build #478 of linux-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/478 22:32:41 <-- mmkmou has quit (Ping timeout) 22:41:36 <Mic> Thanks for both the feedbacks, I think they'll really help. 22:41:46 <Mic> bye 22:41:48 <-- Mic has quit (Quit: Instantbird -- http://www.instantbird.com) 22:43:29 <flo> you are welcome, good night (although I suspect the night may already be over when you'll read this) :) 22:49:34 <-- sonny has quit (Quit: Instantbird -- http://www.instantbird.com) 23:08:07 <flo> aleth: what's the toString() call for in that tab completion patch? 23:08:44 <aleth> flo: array.indexOf uses === not == and match returns an object 23:09:15 <flo> match returns an array, doesn't it? 23:09:53 <flo> if you are sure match will never return null, you could just use [0] instead of .toString 23:10:51 <-- chrisccoulson has quit (Ping timeout) 23:11:01 <aleth> OK, that would work. 23:11:06 <flo> (and I think you are sure, as you return early if word is empty, don't you?) 23:11:14 <aleth> Yes 23:13:09 <flo> I think that patch seems right otherwise 23:14:03 <flo> just another question, if you are in the middle of a nick at the beginning of the input box, should <tab> put the cursor at the end of the nick, or after the {coma,colon}+space? 23:15:16 <aleth> Hmm... maybe. 23:15:59 <aleth> To fully mimic completion, it would make sense. 23:16:35 <flo> yes, it's just painful that it's yet another specific case 23:16:39 <aleth> I hadn't expected that to be something user would try anyway... I suppose it comes with the intro of cycling 23:17:14 <aleth> Well, I might as well add that special case check while I am at it. 23:17:27 <flo> as you like 23:17:38 <flo> if you had wontfixed that bug that would have been ok with me too 23:18:06 <aleth> I was wondering about it, but then I thought, it doesn't cost much time/effort to add 23:19:37 <flo> aleth: another suggestion (feel free to ignore it :)): if I have "aleth, instantbot: " in my textbox, and my cursor is here: "ale|th, instantbot: ", and I press tab, I would end up with "aleth, |instantbot: ", wouldn't it be nice that another tab press moves the cursor to after the next completed nick? 23:20:31 <flo> not really sure if it would be an improvement or a confusing behavior though :-S 23:21:19 <aleth> Apart from the difficulty in adding it, I think it would end up being confusing because if you press tab too often you lose focus of the inputbox? 23:21:49 <-- Mnyromyr has quit (Quit: ChatZilla 0.9.86 [SeaMonkey 1.1.19/2010030105]) 23:21:54 <aleth> Tab isn't Ctrl-arrowkeys... 23:22:29 <instantbot> florian@instantbird.org denied review for attachment 1412 on bug 1410. 23:22:33 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1410 min, --, ---, aletheia2, ASSI, [Tab Complete] Pressing tab while cursor is in a nickname produces garbage 23:22:47 <flo> "if you press tab too often you lose focus of the inputbox?" how so? 23:24:53 <aleth> Oh, that's true, only if the textbox is empty 23:25:04 <aleth> I always assumed it would... 23:25:21 <aleth> Makes sense though 23:27:45 <flo> my advice would be: don't bother too much with things that have no obvious use case ;) 23:29:34 <instantbot> aletheia2@fastmail.fm requested review from florian@instantbird .org for attachment 1413 on bug 1410. 23:29:36 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1410 min, --, ---, aletheia2, ASSI, [Tab Complete] Pressing tab while cursor is in a nickname produces garbage 23:29:53 <aleth> I somehow don't fancy adding a whole special case for when word is empty :-/ 23:30:54 <flo> code readability may be more important than handling all the crazy edge cases we may imagine 23:31:57 <aleth> There seem to be no complaints about not adding a space after a completion within a message so far 23:32:37 <flo> :) 23:33:20 <instantbot> florian@instantbird.org granted review for attachment 1413 on bug 1410. 23:33:23 <flo> Good night 23:33:24 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1410 min, --, ---, aletheia2, ASSI, [Tab Complete] Pressing tab while cursor is in a nickname produces garbage 23:33:44 <aleth> Good night 23:38:33 <-- aleth has quit (Input/output error) 23:52:17 <instant-buildbot> build #569 of win32-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/569