=== jamesh_ is now known as jamesh [13:21] jelmer: poke? [13:22] mathrick@megumi: $ bzr branch git+ssh://git@github.com/mathrick/multiple-cursors.el.git,branch=master [13:22] bzr: ERROR: The repository you are fetching from contains submodules, which are not yet supported. [13:22] but git doesn't seem to see any submodules anywhere [13:26] oh, okay, so it had submodules earlier [13:26] git is a complete trainwreck, btw, there's no way known to #git to check that other than grepping the log for .gitmodules [13:53] jelmer: is there a way to promise bzr I won't use submodules, just check it out already? [14:08] mathrick: hi [14:08] mathrick: you're already using submodules :-) [14:09] howso? [14:09] mathrick: they're in the history - bzr-git requires that it can roundtrip *all* data that is in git into bzr and back out [14:10] jelmer: but isn't "git submodules support" the same as saying "here's a .gitmodule file"? I mean on git's side [14:10] mathrick: no, there's more to it than that - the place where the submodule lives has a magic file with special file modes [14:11] then as long as I'm prepared not to be informed of things (which git submodule already doesn't do anyway), it wouldn't be a lot of a loss [14:11] oh [14:11] mathrick: bzr-git supports converting this into a bzr nested tree and back into a git submodule, but bzr itself doesn't support nested trees properly yet [14:11] that's a shame [14:11] nested trees are probably the oldest planned feature that still doesn't work properly [14:12] jelmer: how are they different from bzr join / split anyway? [14:12] I was never entirely clear on that [14:12] oh, right, nested trees stay independent? [14:14] vila: ping? [14:14] mathrick: yeah, they're a different branch/repository [14:14] mathrick: a nested tree or submodule is just a reference [14:15] the terminology Aaron used was that join/split are "by-value nested trees" and that submodules are "by-reference nested trees" [14:15] any idea how far away they are from working properly? I really remember seeing them planned back in 0.5 days [14:15] that makes sense [14:16] mathrick: I don't think they are going to appear anytime soon, considering bzr's current level of activity and the fact nobody is working on them. [14:17] quicksilver: pong [14:17] jelmer: oh, sorry, I meant more of "how much work would it require to get them fully working", disregarding the fact nobody's doing it atm [14:17] vila: dvc-log (C-x V L) always seems to do "bzr log ", is there a way do just do a plain "bzr log" ? [14:17] (also it seems to be slow when lots of changes) [14:18] quicksilver: sorry no idea, I never use that. Have you tried from a line without a file ? [14:18] mathrick: Quite a lot. I have some thoughts on the best way to approach them, but it's at least a couple of months worth of work. [14:18] vila: how would you bring up a diff between two versions? [14:19] jelmer: oh, ow [14:20] quicksilver: from dvc ? for a given file ? I have a couple of shortcuts defined for 'bzr diff', 'bzr diff -rsubmit:' and 'bzr diff -r $whatever' and that's all I use [14:21] quicksilver: in other words http://paste.ubuntu.com/6044322/ [14:22] quicksilver: fwiw, I just use the plain old terminal (Guake, so it's easy to access) or if doing more, just open bzr explorer and use that. The graphical tree history and diff viewers are just too valuable to give them up for some rather lame integration with Emacs, really [14:23] mathrick: I won't call diff-mode (which dvc uses) "lame" ;) That covers 90% of my needs: overiview of current diff, instant access to modified files, reverting any hunk [14:23] vila: oh, those are useful. I think what I was missing is any way to call bzr-dvc-diff with useful arguments. [14:24] vila: (I meant, any built-in keybinding to call with useful arguments) [14:24] vila: diff mode is very nice in many cases, but a lot of the time, I prefer the qdiff view [14:24] mathrick: I prefer diff-mode to qdiff generally [14:24] better integration with the rest of the emacs workflow [14:24] mathrick: yeah, I can read the qdiff view (and often do so while exploring from qlog) [14:25] * vila nods at quicksilver [14:25] I occasionally use the qbzr stuff to explore things like who committed certain merge subrevisions [14:25] mathrick: but otherwise, full agreement with quicksilver [14:25] often starting from qblame [14:25] speaking of integration, I should bind "bzr qdiff" to something and avoid calling it by hand from terminal [14:25] M-& bzr qdiff [14:26] same here, qblame (which is shorter than qpraise and qannotate sadly ;) [14:26] that's just terminal in disguise [14:26] * vila blinks [14:26] quicksilver: holy cow, why did I never thought of binding qblame and qlog in the dvc buffer... [14:27] mathrick: you mean M-x shell ? ;) [14:27] truth is shell-mode lacks a lot of terminal goodness, there is a lot to be said about completion for example [14:28] (yeah I know it's more bash than the terminal itself) [14:28] either way, now that I've cleaned up my emacs config, I can actually look at binding bzr sensibly into my workflow [14:29] mathrick: seriously, you managed to really clean it up or was it more like "reasonably clean up" ? ;) [14:29] * fullermd . o O ( <--- has an rm if you need to clean emacs up... ) [14:29] * vila manages to remove stuff at each upgrade but some pieces are there for decades (literally ;) [14:30] mathrick: it is and it isn't. [14:30] vila: https://github.com/mathrick/emacs-config vs. https://github.com/mathrick/emacs-config/tree/16fe55f48771768ae448b826f1ef3fc99da5841a :) [14:30] mathrick: it saves you switching window and it has a separate command history. [14:30] fullermd: vade retro satanas , we all know your number is VIVIVI [14:30] vila: tell me about it, I removed some 15 yo junk from tit [14:30] mathrick: :-D [14:30] protip: (setq foo 42) is not the proper way of making function-local variables... [14:31] * mathrick smacks younger mathrick up the head [14:31] in my defence, it was my first contact with both emacs and lisp of any sort [14:32] vila: I've been putting off the cleanup itself for years, and I basically reached the point where I couldn't really install a package because there was no way to stuff it into the pile of mess my config was without doing some sort of cleanup, so I did [14:33] technically I've been "using" grail.el for a few years, but that was really little more than just mv .emacs ~/elisp/user.el plus some load-path magic [14:33] hehe, that's a good reason ;) [14:33] vila: if you want, take a look at the readme, I've actually documented it and made sure to make it bootstrappable [14:33] I have verified that I can bring up my config on a vanilla emacs with a single command, including emacs23 :) [14:34] I haven't installed a emacs package yet [14:34] oh, man, ELPA is glorious, especially if you pair it with Cask/Pallet [14:34] I needed to hack them to stop assuming ~/.emacs.d/, but they work and I have no junk at all in there [14:35] vila: https://github.com/mathrick/emacs-config/blob/master/Cask <-- this is how I store my deps in bzr [14:35] wow, single command, nice, my setup have been following me from sunos to solaris, osx, freebsd, gentoo, ubuntu, all with minimal tweaks but I also relies on bzr to keep them all under control [14:35] no checking in external libs \o/ [14:36] wow, nice [14:36] vila: yeah, I've done some work on win32, which made the config all that more horrible, and it'd take me a day to get it to work on whatever zany version I managed to get to run [14:37] ha yeah, win32 too but only slightly [14:37] one problem I haven't solved properly yet is how to track non-ELPA packages [14:37] it will require some legwork to integrate VCS checkouts as much as at all possible with Grail [14:37] yeah, I don't try, I manage to keep all dependencies optional [14:37] "be as smart as possible but not smarter" [14:38] vila: yeah, that too, will do it simultaneously I guess [14:38] I've been using 3 small packages for which I keep the source [14:38] right now I just assume all of ELPA will install [14:39] actual win32 testing presumably will teach me to know better than that :) [14:41] vila: if you want, I can ping you when I'm done with that, I actually plan to make a skeleton branch which is that except with all my config removed and only the support bits left in [14:42] mathrick: I'd love too, but I keep the little free time I can gather here and there to bzr :-/ [14:42] aye [14:43] vila: I decided to do it now, because I've been honestly avoiding doing actual coding work out of fear of dealing with the packages I'd need to install onto my old mess [14:43] and that's just not good [14:44] oh, right, one thing you WANT to check out: http://emacsrocks.com/e13.html https://github.com/magnars/multiple-cursors.el [14:44] it's absolutely fantastic, and managed to supplant CUA-rectangle which I've been madly in love with for years [14:45] quicksilver: ^ you too, if you don't know it yet [14:45] works best when paired with https://github.com/magnars/expand-region.el [14:49] mathrick: hmpf, I'm not even sure I will be able to use that O_O granted it looks nice (multiple cursors that is) [14:49] oh, you will [14:49] it's instantly useful everywhere the moment you have it available [14:49] mathrick: note that I'm still quite new to CUA-rectangle [14:50] vila: think of it as better CUA-rectangle, which is already pretty damn great. All kinds of refactoring is possible, and it serves a fantastic replacement of macros and regexes in many cases [14:51] Sheesh. Why would you want to replace a regex with anything but a more complicated regex? [14:54] vila: for example, https://github.com/magnars/multiple-cursors.el/issues/76#issuecomment-23531660 <-- I wrote it writing all key sequences like [C-u C-x n n] [14:54] then replacing them with the fantastically readable C-uC-xnn, then selected all such instances and converted them to [14:54] er [14:55] aside from the fact my xchat buffer got messed up [14:55] * quicksilver doesn't even use CUA-rectangle [14:55] I use builtin rectange commands every day though [14:56] quicksilver: MC is that on steroids. You'd use either built-in rectangles or CUA-rectangle, but MC is strictly better than both [14:56] because it doesn't require you to have consecutive, aligned lines [14:58] intersting. [14:58] quicksilver: watch that screencast, it explains perfectly what it's useful for [14:59] yeah, sounds interesting, I wonder though if that won't make myself a bit lazier for refactorings... [14:59] well, shows, which is even better [14:59] vila: what do you mean? [14:59] why do the best emacs tips always come as off-topic conversiations in other channels? [14:59] because Emacs is too big to be a single topic! [14:59] if there are multiple lines where I need to apply the same modifications, shouldn't that be abstracted ? [15:00] mathrick: the more powerful your editor, the more likely you are to put up with ugly boilerplate / repated code [15:00] just look at Java ;) [15:00] serendipity, thy name is Emacs :) [15:00] quicksilver: yeah, I know [15:00] but it also makes it really easy to refactor things [15:00] but the example where he handles the i18n is different, there, it *helps* the refactoring hugely [15:01] Well, because most localities have banned door-to-door emacs proselytization, so the pushers have gone online to tempt children into the ways of sin... [15:01] so "meh, I don't feel like fixing it in 5 places, I will paste it once more" is no longer an excuse [15:01] mathrick: I think the simpelst thing to do if you can is to fastexport/fastimport the git repo to remove the submodules, and then redo the bzr-git command. [15:01] jelmer: doesn't really work for pull requests though :\ [15:02] mathrick: ah, yeah.. [15:03] jelmer: oh, speaking of that, how can I replay a fi stream on top of a repo? I have a repo which starts out with a file structure identical to a git repo I want to graft onto, but the history is different and includes other junk. I wanted to filter out all but the files I care about, but replays don't work, they simply replace everything rather than adding to the history [15:04] specifically, https://github.com/codermattie/Grail and https://github.com/mathrick/emacs-config/tree/16fe55f48771768ae448b826f1ef3fc99da5841a [15:04] my repo starts with grail files textually identical (they were downloaded as blobs from github), but the history is interleaved with everything that happened to my repo [15:05] mathrick: OK, I watched the screencast. I do stuff like that all the time but I have to use a cmobination of rectangle commands, align-regexp, and regexp replace. Neat. [15:05] I want to isolate just the things I did with grail*.el and graft that on top of a Grail checkout [15:05] quicksilver: yep, it removes a lot of drudge regexp hackery from my day [15:06] and trying to divine why align-regexp doesn't work and is it still saving time if I debug it? [15:06] mathrick: sorry, not sure about that. [15:18] jelmer: hmm, any idea who knows about bzr fast-import? [15:23] mathrick: I think Ian and myself are the main people who have worked on it [15:23] I swapped that stuff out a long time ago :) [15:23] perhaps try the list? [15:24] will do [15:24] thanks [21:07] hey, I was wondering if a plugin existed, to kind of, 'pin' a file. I have a file that is dynamically generated and the contents differ occasionally on a rebuild, and i don't want to commit it each time as its derived from something else, but i don't want to ignore the file either cause then it wont get checked out if someone branches the repo [21:54] mgrandi: no, there isn't anything like that. generally what happens is that people check in foo.in, and then have a build script that copies foo.in to foo and makes local modifications to it [21:55] (and then add 'foo' to the ignore list) [21:59] I suppose locally you could have a pre-commit that drops that file from the list of changes to commit. [22:00] But that won't help casual developers avoid committing it unecessarily. [22:23] yeah [22:24] i might do that, thanks jelmer