#instantbird log on 04 28 2012

All times are UTC.

00:11:15 <-- Tonnes has quit (Quit: ChatZilla [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