Hi Hannu, Thanks for the feedback. I didn't get a chance to respond properly earlier.
At Wed, 15 Sep 2010 00:58:46 +0300, Hannu Koivisto wrote: > > Óscar Fuentes <[email protected]> writes: > > > I've played for some minutes with the feature. I see that Phil > > I also moved on top of this feature (latest master) plus gazillion > other commits and have been experimenting with everything. > > So far key-groups feels more of a hindrance than a benefit, > although I can imagine that after some changes it might work for > me. I recognise the rough edges and we can work through the problems and hopefully reach a happy medium for people. > > Text is wider than the buffer (see logging on a 80 character wide > > frame). The old implementation adapted the display to the number > > of columns of the window. > > That is something I noticed as well (with branch group). I've fixed this. Will push it soon. > Key combinations like b V and b B are inconvenient, you have to > press shift in between. I did that because B and V performed the same actions retrospectively in the old code. Please do suggest alternatives and we decide on what to go with. > I would have preferred to keep the old rewriting key sequences (r s > to start instead of r b (to begin)). I took the opportunity to put them closer to their command line equivalents. > The greatest annoyance so far: I very much preferred to control > amending and committing all (in case of nothing in index) before > writing the commit message. I don't even understand how amending > works anymore; what good does it do to enable that _after_ hitting > "C-c C-c"? How can I edit the old message? Also, in case you have > nothing in index, it's weird that only after writing a commit > message for something you don't even know you can commit directly > you can ask to do exactly that :) C-c C-c c is also inconvenient, > C-c C-c C-c would be easier to type (no need to lift control in > between). But even better would be to drop the whole option thing > after C-c C-c and have means to toggle options while you are > writing the commit message (which should really be considered to be > one option among others). Yea, it turns out I've broken amending altogether. I'll revert all of the log stuff and think about it more carefully for a better implementation later. > It's bad that commands like where-is and describe-key don't play > along with key-groups. Yea, the reason I made it a mode was to benefit from these things. Again, will have a think about how to leverage emacs style help. > magit-define-command feels questionable. Makes it difficult to > find command definitions. Especially in its current misguided form > which prepends magit- to the sym argument instead of requiring the > actual symbol. Lacks debug declaration. defadvice would probably > have worked just fine for current minimal use (apparently only > magit-topgit.el) with the benefit of documentation support. I have > to think about alternatives. It's not perfect but I like it much more than advising functions. Just because only one plugin uses it now doesn't mean others won't in the future. Thanks again, Phil.
