[00:16] help, anyone around? [00:17] Dragging and dropping an exported yaml from gui doesn't accept the file, I simply get the file downloaded again [00:17] Google Chrome [00:18] and Firefox [00:18] about to demo, using jujucharms.com public deployment [00:30] marcoceppi|away: Seeing the same thing. http://comingsoon.jujucharms.com is erroring when I try it too. [00:30] huwshimi: this is really unfortunate :\ [00:33] marcoceppi|away: Can you drag charms from the sidebar onto the canvas? [00:33] huwshimi: I can, I did mocked a large HA OpenStack deployment earlier [00:34] it works and it's up, but I've dropped internet connection a few times so I wanted to reload the page to get the last missing charm [00:34] I'm going to just wing it though for now [00:34] If it's not working post-meeting I'll open a bug [00:35] marcoceppi|away: OK. I'm not getting any errors so the drop targets might not be working somehow. If you can check if it works in http://comingsoon.jujucharms.com [00:35] that would be good [00:36] huwshimi: I get an environment import failed, Unparsable environment data [00:36] marcoceppi|away: OK, that's what I get too [00:37] which is a step up from it not accepting the target [00:37] for refernce: http://paste.ubuntu.com/5975549/ [00:37] huwshimi: thanks for confirming, about to demo [00:38] marcoceppi|away: Hope it goes well! [00:42] huwshimi: any idea on IE support paths? [00:43] marcoceppi|away: For this issue? [00:43] huwshimi: no, just in general [00:43] what's the lowest (if any) supported version of IE? [00:44] We try and support IE10 fully, but there are some outstanding bugs (https://bugs.launchpad.net/juju-gui/+bugs?field.tag=ie10) [00:44] We are working towards them at the moment [00:51] marcoceppi|away: is the feature complete? I know there's work around deployer formats and such in progress [00:51] marcoceppi|away: I had that same issue while testing in sprints and was told it wasn't done yet [00:52] marcoceppi|away: if you got the unparseable environment data that might be the format switch [00:52] marcoceppi|away: ie10 is only supported version and some known bugs in progress. https://bugs.launchpad.net/juju-gui/+bugs?field.tag=ie10 [00:54] rick_h: well the file came from juju-gui [00:54] rick_h: I assuemd it could read what it created [00:54] rick_h: thanks for the info! [00:54] marcoceppi|away: right, but in the last month the format changed around? I'm only vaguely familiar [00:55] marcoceppi|away: https://canonical.leankit.com/Boards/View/102529849 is a card in progress [00:55] rick_h: yaml support was added, but I'm not aware of format changes. I don't follow the deployment that closely [00:55] * rick_h isn't sure if you can read that :/ [00:55] marcoceppi|away: yea, me either while is hurting getting you help [00:55] but a card in progress from bcsaller right now is titled "import deployer format" [00:55] rick_h: well that's good to know, since i'm writing an abstration layer for deployer files [00:55] rick_h: it's okay, I've still got the original deployment in a browser tab [00:56] we can make it through this [00:56] marcoceppi|away: yea, sorry. You can cli that? [00:56] * rick_h isn't sure how that works cli -> gui and back [00:56] rick_h: well, I don't want to actually deploy it, since it's a huge openstack install [00:56] marcoceppi|away: ah, gotcha [00:56] rick_h: no, it was jujucharms.com gui -> disk -> gui (error) [00:56] I haven't actually done that deployment [00:56] just wanted to be flashy about it [00:56] I see [00:58] rick_h: huwshimi: thanks! === marcoceppi|away is now known as marcoceppi|trave === schwuk_away is now known as schwuk === gary_poster|away is now known as gary_poster [13:13] abentley: good morning; I have fixed up my branch, if you have a moment to look it over: https://code.launchpad.net/~benji/charmworld/featured-breakout/+merge/179503 [13:14] benji: Have you pushed your branch? I don't see the fixes you're talking about. [13:14] "Pushed up to revision 343." [13:15] benji: The current diff is still adding qa: None [13:15] Line 104 of the diff [13:16] My IRC app is flaking out. Back in a sec. [13:16] ccccccbljtrvvbbchjvnjubrkcnjhuhvbkrbvihcuunj [13:16] ccccccbljtrvhgivfevfvkdfkbjegleuutfhchunbkkv [13:16] =]\['\] [13:17] ...i walk away from the computer. i come back and my dog is pawing at it on the coffee table. [13:17] abentley: fixed and pushed [13:17] ....when did my dog become a cat? [13:17] heh [13:19] benji: Also at 486 [13:19] yow! I really botched that merge. [13:21] fixed and pushed [13:25] dentist, biab. I am tweaking Huw's branch. [13:28] benji: r=me [13:36] benji: Wait a sec, I don't think this works, because you're storing charm_ids. [13:36] benji: And I'm making charm-ids versioned. [13:37] benji: So we would have to update the featured charm-id every time. [13:37] benji: I.e. every time we ingest. Which is exactly the kind of thing we don't want to do. [13:46] hatch: ping for when you get in. Need to chat login code. [13:48] abentley: I thought that the (revisionless) charm ID would be good for featured charms, since only ownership changes or series changes would affect the ID [13:49] benji: You are storing the soon-to-be-revisioned charm-id as an attribute at line 68, AIUI. [13:50] abentley: I am, and when it is revisioned we'll have to change that [13:52] benji: I proposed that you store name, owner and series in the document. That will work now, and it will work in the future, too. But if we do it in the future, we also have to do a migration to change it. [13:53] benji: So let's do it now, so we don't have to do the migration later. [13:55] abentley: my concern with that approach is that constructing the set of featured charms for the API would then become N searches, one for each charm. Is that going to be fast enough? [13:57] benji: I think we could construct a single search with an OR block at the top, so that we could use a single search to find all the charms. [13:57] orangesquad, can everyone join a hangout in a few minutes? [13:57] sinzui: rgr [13:57] sinzui: Sure. [13:57] sinzui: rgr. [13:57] sinzui: our standup hangout? [13:58] rick_h, Do you still have a link to it? [13:58] * sinzui looks in browser history [13:58] sinzui: yea, in my calender sec [13:58] rick_h: hey, just going to grab a coffee then ready to chat [13:58] oh shoot, I did but guess not. [13:58] abentley: ok, I'll take a stab at that approach. To be clear, running that query would result in all revisions of all featured charms and we would then drop the non-latest, right? Or is there a way to query for only the latest revision? [13:58] hatch: will be a few [13:58] hatch: sorry [13:59] oh. maybe I do remember it [13:59] sinzui: https://plus.google.com/hangouts/_/9e4f8e4352c744b862c522c70e8fdde42f531f57 [13:59] orangesquad ^ [13:59] orangesquad: be there in a moment. [14:00] adeuring, can you join this hangout ^ [14:00] * adeuring is coming... [14:58] abentley: can a revision of a charm ever be removed? [14:59] benji: I am assuming no, for a given instance of charmworld [15:00] https://docs.google.com/a/canonical.com/document/d/1IP02eriK3TlaIeyL_3gXnCmPQphRDrtUi3jAm0kpGeU/edit [15:03] sometimes I wish js had real interfaces [15:15] hatch: I'm about to relocate but while I'm in transit let me know if there's any reason I shouldn't do http://paste.mitechie.com/show/998/ to fix #1199392 [15:15] <_mup_> Bug #1199392: can't view fullscreen charm details from url

[15:16] orangesquad, I I think saucy decided the meeting is over. [15:17] I have nothing left to say [15:17] sinzui: thanks for he info. Going ot relocate back to real interwebs back home then. [15:20] benji: Sorry, was in a meeting. [15:22] abentley: could you please update staging to r341? [15:22] benji: Yes, when charms are versioned "running that query would result in all revisions of all featured charms and we would then drop the non-latest", just as we're doing with other searches. We might switch it to Elasticsearch later, since that's versionless. [15:22] adeuring: Sure. [15:22] abentley: ok, thanks [15:24] rick_h: i dont see any issue pending QA is ok [15:25] adeuring: done. [15:25] abentley: thanks! [15:28] hatch: k, I wasn't sure on this login event and why this is going on. I'm not sure how best to get some tests in there because I have to url mangle and the test suite won't like it [15:29] rick_h: yeah this is all wako becuase the login comes from the ws [15:29] hatch: k, thanks for the sanity check [15:29] rick_h: maybe we should create our own 'url manager' which handles fetching things like window.location [15:29] so that we can actually test these things [15:29] hatch: well I'd expect it in the ns-routing [15:29] hatch: but his code is diong it's own dispatch call [15:30] hatch: and only dispatching the small little path it knows/wants to know about [15:30] well I'm just saying we can't unit test this login method because it pulls right from window.location which asyou said will bust up the tests if we change that [15:31] so if we had it pull from 'fake().window.location' [15:31] then we could mock it [15:31] I'm not saying you should do this now [15:31] :) [15:31] hatch: ugh, well I'd rather that it didn't use pathname at all, but it's fed that already upstream [15:31] but use the whole url [15:32] yeah I was thinking that too but then we have to deal with parsing out multitutes of base urls [15:32] hatch: right [15:32] still doesn't make it any easier to test though [15:32] hatch: well then I don't need my change at all :) [15:32] I just need to get the whole url into the navigate call [15:33] I suppose you could change the regex's to parse the full url [15:33] not sure if that's any less work though [15:33] hmm, maybe I don't care about that. If we hit this else block why can't I just use window.location.url? [15:33] vs the redirectPath. [15:34] because the redirectPath can be set by external stuff [15:35] hatch: guichat? [15:35] sure [15:50] jujugui call in 10 kanban now [15:51] Thanks Makyo. Also, jujugui, orangesquad, early warning that this meeting may go over a bit, reviewing some of the changes from the past week.. [15:51] story time! [15:52] weeeee! [15:52] :-) [15:52] * hatch grabs his blanky [15:52] lol [15:52] as my son would say " [15:52] "criss cross apple sauce with a bubble in your mouth" [15:52] heh [15:52] lol what? [15:53] it's how the kids sit at day care. Sit on the floor with criss-crossed legs and your mouth closed as if it had a bubble in your mouth [15:53] ahh - smart teacher [15:53] and keep it closed tight so the bubble doesn't get out [15:53] lol [15:53] oh yea, great for story time [15:53] so where does the apple sauce come in? [15:54] rhyming, kids love it [15:54] * bac likes apple sauce [15:58] jujugui call in 2 [16:02] sinzui jcsackett call ping [16:02] gary_poster, google refuses to believe I am logged in [16:03] ack sinzui :-( proceeding with kanban for now but let us know if you want us to wait on anything [16:38] gary_poster, May be misreading the UX by unit bit, actually. It looks like it's listing charms, rather than units. [16:39] Makyo, ah, yes [16:39] gary_poster, Which we can do for up/downgrade, but not cross-grade, which I guess is okay. [16:39] review time! [16:39] That would leave cross-grade as some manual step for CLI. [16:39] Makyo, right, I thought crossgrade would be a bit much for the GUI [16:39] Yep. [16:39] at least for now [16:39] cool, thanks for reviewing it again Makyo. [16:41] jcsackett: url for your branch? [16:41] sorry my email is being dumb [16:41] hatch: https://codereview.appspot.com/12768043/ [16:41] thanks [16:44] jcsackett, did you merge trunk into your branch? [16:49] hatch: i believe so. [16:49] hatch: what makes you ask? [16:50] just curious [16:51] I also added a note tot he code review wondering if we should rename it from browsercharm in the cleanup [16:51] thinking that browser is going away :) [16:53] hatch: we want to keep a distinction between browsercharm and charm right now. [16:53] when we remove the charm model code we'll also rename browsercharm. [16:53] right right of course [16:55] hatch, I didn't understand what you meant in #1211356. could you be a bit more concrete in bug? [16:55] <_mup_> Bug #1211356: service configuration is used in too many formats [16:56] gary_poster, sure - I added a card to talk about it on Friday as well [16:57] cool thanks hatch (but I won't be there, so I want a clue too ;-) ) === schwuk is now known as schwuk_away [16:57] gary_poster, oh right....ok updated [17:09] gary_poster, does the new description make a little more sense? [17:11] hatch maybe :-P . on a charm, the config is about schema, while on the service, the config is about values, so that seems reasonable to be different, unless there's a simple way to unify them. The template diff sounds clearer on the face of it. [17:13] yeah this is mostly about requiring you to run a util parse method on the service data in order to render it [17:20] Makyo, is there any QA required for your branch? [17:21] hatch, if you would be so kind: change 'python' to 'go' in app/config-debug.js and deploy a service - it should have units in the inspector, a health graph on the service, etc. Should be quick. [17:22] will do! [17:40] rick_h, do you use irssi for irc? [17:41] hatch: yes [17:42] I'm trying to decide between that or quassel [17:42] hatch: weechat is the one to check out these days [17:42] hatch: I've just not bothered to switch my config over atm [17:42] since I've had this setup for so long [17:43] it's been around for 10 years and isn't even at version 1 [17:43] lol [17:43] welcome to OSS [17:43] what is this...a nodejs script? [17:46] Makyo, review and qa done [17:47] rick_h, hmm it looks pretty cool [17:47] jcsackett: qa issue: http://gui:8888/:gui:/charms/charms/precise/ceph-14/json/ auto reloads over and over [17:47] nice UI....console [17:47] hatch: yea, if I didn't already have a setup I'd be using weechat and one day when I'm bored I'll port over [17:48] I really want to setup a irc client which is always running so I can just hook into it as I move from computer to computer [17:48] hatch: yea, <3 [17:49] hatch, Until pyjuju is fully deprecated, I would assume the pyjuju sandbox will remain, but perhaps someone else from jujugui can comment. +1 on splitting into separate files if possible, though. Will make a slack task. [17:49] have you used/looked into quassel? [17:49] Makyo, yeah I kind of figured as much, cool [17:49] hatch: graphical? no...I've not looked at it [17:49] jujugui lf two reviews on https://codereview.appspot.com/12770043/ [17:50] rick_h, well it also has a server component [17:50] yea, no thanks [17:50] just use weechat and be happy [17:51] I'm going to built up my terminal and try and go cold turkey [17:51] let me know when you need a hang :) [17:51] hand [17:51] tmux, weechat(I guess :P), vim? [17:51] yep [17:51] when you get ready for mutt let me know :) [17:52] Haha [17:52] haha no [17:52] that'll never happen [17:52] best email client out there! [17:52] * rick_h hugs mutt [17:53] ya know I say that.....but who knows! [17:53] your horrible terminalness is rubbing off on me [17:54] I'm a horrible influence, just ask the locals around me [17:54] gary_poster, shall I continue on the inspector tasks? Did you want anything in particular done right now? [17:54] I bet! [17:55] rick_h, I love how mutt's feature list includes 'color support' lol [17:55] hatch: yea, very handy [17:56] Need to switch from screen to tmux one of these days. [17:56] Makyo, yeah, even I know that's the right move :) [17:56] I'm just so used to screen. Will take some effort. [17:56] Makyo: the pragmatic prog tmux book helped me switch. Really handy read [17:56] rick_h, how does mutt handle html emails? [17:57] hatch: so I patch it through to w3m for the most part, or else I open them in chrome through mutt [17:57] ahh ok - just curious really [17:57] yea, most I can read in w3m, a command line browser. Otherwise you can write the message out to /tmp and them chrome them [17:58] the reason I'm considering vim at all is that I pretty much navigate through sublime with keyboard shortcuts anyways and switching between irc/sublime/terminal is getting to be a pita [17:59] have you ever heard of a tiling window manager? /me runs away cackling [18:00] lol yes [18:00] So...vim + ctrlp \o/ [18:01] Makyo: glad you like it :) [18:01] Yeah! [18:01] * hatch goes to google ctrlp [18:01] see, this is what's great about sprints. You walk away with new side things that are awesome [18:02] rick_h, Makyo ahh yes sublime does that with ctrl+p :D [18:02] guess I could have assumed lol [18:06] rick_h, I know I asked this before but I can't remember the answer - do you use a vim window manager or tmux for different windows [18:07] hatch: I use my tiling WM and lots of splits in vim. I don't use tmux to window/split [18:07] ahh right right [18:08] and is there anything in vim which has the idea of a 'project' [18:08] jcsackett: nvm I guess. I can't dupe now. The code is going away soon as well so carry on! [18:08] meh, that stuff is too much imo [18:09] hatch, bcsaller, would it be reasonable for hatch to tackle the scale up/down ux? [18:09] gary_poster: Thats fine with me, but I can get to it once I've finished this import stuff [18:12] bcsaller, if hatch thinks scale up/scale down is a good task, then you could prototype how to use the sandbox + topologies to display bundles in the charm browser [18:12] gary_poster: that sounds like a good use of time to me [18:12] cool bcsaller [18:12] and fits well with the import story [18:12] y [18:13] alright I'll take the scaleup/down [18:13] cool thanks hatch, bcsaller [18:13] sinzui: wanted to check in on the deploy docs and process for charmworld? [18:13] bcsaller, did you have any work done on it yet? [18:14] abentley, I see staging is at r341. Do you have any reservations if we deploy it for rick_h? [18:15] hatch: I didn't take it very far, I'd just started with the template. Mostly I moved to the import stuff. I'm happy to do a pre-imp call though [18:15] sinzui: Let me check... [18:16] sinzui: I'm looking at 342 as my icon branch didn't really require updating staging. [18:16] sinzui: No, I'm happy. [18:16] abentley, fab. [18:16] rick_h, are you saying staging is 1 rev behind? [18:17] sinzui: yes [18:17] bcsaller, sure in a bit - I'm just fixing some IE test failures [18:17] rick_h, we need to see it on staging to verify the charm can stop and start for the rev [18:18] sinzui: Staging still isn't auto-updating on branch landings. [18:19] abentley, I was going to run the tests for 342 then juju set revno [18:19] sinzui: Yes, that's what we have to do right now. [18:20] sinzui: ok [18:20] sinzui: But you could also go straight to 344. [18:21] works for me [18:21] jujugui 2 reviews please for tiny diff to fix #1199392 https://codereview.appspot.com/12791043 [18:21] <_mup_> Bug #1199392: can't view fullscreen charm details from url

[18:22] rick_h: i'll do one [18:22] bac: thanks [18:23] bcsaller, the upgrade story is on mockup v11 or did we have a different one for it? [18:23] hatch: upgrade charm ux? [18:24] hatch this isn't the upgrade story but the scale up/down story [18:24] ohh ok so we are using the v11 version? [18:25] hatch, upgrade charm ux: https://www.dropbox.com/s/d6sc200adk2dszs/juju-gui-2-inspector-09.jpg [18:25] think so. verifying [18:25] Just so you can diff them [18:25] yup pretty close thanks [18:26] ok I'm going to grab lunch first then get started on this [18:27] cool. and yes, v11 should be it [18:35] rick_h, staging updated. Are you satisfied it has the feature you need? [18:36] sinzui: yes, thanks! [19:05] jcsackett: hatch can I interest either of you into a small itty bitty review? https://codereview.appspot.com/12791043 [19:05] mayyyybe [19:06] rick_h, so you're going this way instead of a util method eh? [19:06] hatch: yes, a util method isn't needed and needs a home, and doesn't get me anything as then it needs tests that muck with the url [19:07] I'm not sure I agree because this way we can't unit test this method [19:07] although we had this discussion already [19:07] haha [19:07] sure we can, override the getter as we talked about. It's 'a util method' [19:08] just in an attr atm right next to the code using it that needs it [19:08] we can override the getter? [19:08] but it's ugly, I give you that [19:08] hmm, can't you override the getter of an ATTR? [19:09] I didn't think so [19:09] maybe you can and I've been missing out... [19:09] * rick_h didn't look I guess. It's a function, why not be able to override it [19:10] I think you have to pass in a named fn and override that one because I am pretty sure YUI doesn't give you access to the getter fn's after instantiation [19:11] ok, well this can be pulled into a util when someone else needs it. For now it seems like fixing this special onLogin event issue with a sledgehammer [19:11] and woot, autocomplete landing. /me keeps refreshing comingsoon [19:11] lgtm'd [19:12] thanks [19:12] gary_poster: sinzui so autocomplete is out the door and bug fix. Is there a priority from here I should take into account? inspector cards? other browser bugs? should we chat on some of the new ones that came out of IoM? [19:13] rick_h, awesome~ [19:13] ! [19:14] rick_h, working up answer. have a glass of water. ;-) [19:15] gary_poster: np [19:19] rick_h, how about (dun dun dun!) the STICKY HEADER CODE! [19:20] rick_h, you can say no, but, your mission, should you choose to accept it... [19:20] * rick_h pretends gary_poster was talking to hatch :P [19:20] lol [19:20] * hatch pretends he doesn't exist and can't be assigned this tasks [19:20] lol [19:20] gary_poster: k, I don't have all the background. If you can link me to the notes/info I can look into it. I've seen a couple of links of demos from hatch [19:21] rick hop into guichat I can give you a rundown [19:21] ...would be to get a simple variant of sticky headers working in the inspector and the charm browser. [19:21] hatch: k [19:21] gary_poster: ok, yea I've seen the card about a demo, but know there was some confusion abuot when/how it was used as well? [19:22] hatch, do you have a link of the FF demo? Please emphasize that we should go with something quick rather than something perfect--we can negotiate with UX, but the user testing said load and clear that the sticky headers were helpful [19:22] yep definitely [19:22] I think I have the link somewhere I'll have to look [19:23] thanks hatch. rick_h, the confusion was that we thought it needed to be implemented a certain way. what UX actually wanted seemed easier and more common, but turned out to be harder. hatch knows where the bodies are buried. I can hop on the call at a moments notice if desired [19:24] gary_poster: k, thanks. Chatting now [19:29] bcsaller, I suspect you want to do this almost as much cutting your fingernails to the quick, but we do have you done for "Write documentation for Databinding Engine and Controller" and that is something that both of your reviewers requested. [19:29] s/done/down/ [19:30] That would be a good task to complete before you move to the prototype. [19:30] hi sinzui [19:30] hi bac [19:30] sinzui: you got a sec so i can pick your brain? [19:30] yes [19:31] sinzui: guichat is occupied. i'll make a hangout [19:32] sinzui: you are unavailable. :( [19:33] I am here [19:33] in g+ [19:34] I am trying to call you [19:34] jujugui, could I have two volunteers for charm reviews today of frankban's branch, please? https://codereview.appspot.com/12770044/ [19:35] sinzui: it thinks i'm in a call with both of your identities and it won't let me join either! [19:35] gary_poster: I'll take one [19:35] thanks benji [19:35] bac, ring me again? [19:35] yes, the non-canonical you [19:36] gah, killed ff and am trying again [20:03] bcsaller, have a moment for that pre-imp? [20:07] gary_poster: autocomplete is on comingsoon. Do we still have the css build issue on there as it looks funky? I've got to run but will look into it in the morning if needed. fyi [20:08] rick_h, ack, thanks, will investigate [20:16] rick_h, was a conflict *and* a build issue. :-) resolved [20:31] hatch: sorry, was at lunch, want that call now? [20:31] yup lets do it [20:32] http://pastebin.ubuntu.com/5959504/ [20:36] gary_poster: want to pop into guichat for a second? [20:36] abentley: I've upadated my branch to not depend on charm ID [20:36] hatch will be there in 5 [20:36] benji: Looking... [20:38] benji: While waiting on your branch, I've been working on removing doctype: https://bugs.launchpad.net/charmworld/+bug/1208477 [20:38] <_mup_> Bug #1208477: Bundle metadata contains redundant "doctype" attribute [20:39] abentley: hmm, I think doctype is pretty important for my branch [20:40] benji: The caller should know what the document type is. [20:41] abentley: right, but how will the FeaturedSource know what kind of document it has been given? [20:42] abentley: I'm sorry, but I really have to run an errand right now, I'll be back later but I suspect we'll have to iron this out in the morning [20:42] benji: The caller can pass that info in. It already does for get_featured. [21:28] sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-doctype-attribute/+merge/179814 ? [21:29] * sinzui does [21:30] abentley, r=me [21:30] that was nice without a single surprise [21:31] sinzui: The surprise for me was that Elasticsearch doesn't support bulk updates. [21:37] sinzui: could you review https://code.launchpad.net/~bac/charmworld/create_replacemet-bundle-aware/+merge/179816 ? it is the fix we discussed, i just pulled it out into a bite-sized branch. [21:38] * sinzui looks [21:40] sinzui: with this fix, bundles added before running bin/es-update survive. [21:44] bac: Your have two tests of similar name, but they do different things with create_replacement() [21:46] bac maybe the names could be test_create_replacement_default_bundles() and test_create_replacement_with_bundles() [21:47] sinzui: i followed the existing pattern with charm/charms. [21:47] hmm. [21:47] sinzui: but i'm happy to change the names of them all to be clearer [21:48] bac, could you? That's all I ask. r=me [21:48] sure. thanks sinzui [22:08] bcsaller: what do you use for vim to allow you to use the mouse the way you do? [22:08] do you use gvim? [22:09] hatch: no, console vim. I think its :set mouse a [22:09]