gwh's SlackBuilds
cf60063e3b
Introduces
magit-log-buffer-name *magit-log*
magit-log-edit-buffer-name *magit-edit-log* (was *magit-log-edit*)
magit-log-grep-buffer-name *magit-grep-log* (was *magit-log-grep*)
magit-process-buffer-name *magit-process*
magit-commit-buffer-name *magit-commit*
magit-stash-buffer-name *magit-stash*
Also adds C-c C-] as a binding for magit-log-edit-cancel-log-message
since C-c C-] as the aborting counterpart to C-c C-c is at least a
vague convention for other modes (cf. rmail, vm, query-replace...)
Motives:
It annoys me that, when wanting to switch to the *magit-log* buffer
from some random place, I can't type *ma<space>-l<space> and have it
complete properly, at least not if I've previously ever done a commit
(because there's then a *magit-log-edit* out there stealing the
completion).
Also looks like if I ever use magit-log-grep, I will be likewise
screwed.
Finally, it disturbs my sense of aesthetics when I look at source code
and see the same strings occuring over and over. Usually, that's
crying defvars/defconsts. (And this will also makes life easier
in the event you don't like my buffer name changes for -log-edit
and -log-grep).
- -
(...This all leaves *magit-tmp* as the only remaining case of a buffer
name string occurring multiple times, but that needs to be handled
differently, so that'll be a different patch...)
(...Note that having buffer names as variables also allows the
eventual possibility of making them local --- or at least the
option thereof --- so that one can be visiting several
repositories at once and not having these buffers all clobbering
each other. There's a tradeoff here in that some folks may find
it confusing/annoying to have more than one set of these buffers
to deal with,... hence option.
*If* one is going to go that route, current gut feeling is buffer
name variables should be local to *just* the status buffer(s),
void elsewhere, and anything needing one of the auxiliary buffers
should dispatch through its own status buffer to get what it
wants. That way, we're not having to repeat/update/copy
per-repository definitions everywhere....)
The patch:
|
||
|---|---|---|
| test | ||
| .gitignore | ||
| 50magit.el | ||
| AUTHORS | ||
| autogen.sh | ||
| ChangeLog | ||
| configure.ac | ||
| COPYING | ||
| fdl.texi | ||
| magit-pkg.el.in | ||
| magit.el | ||
| magit.spec.in | ||
| magit.texi | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
It's Magit! A Emacs mode for Git.
I started to write Magit to learn about Git and to figure out how I
would be using Git in a 'natural' way. Magit will grow and hopefully
become more coherent as I learn more about Git and good ways to use
it. Feedback is welcome!
* Installing
Magit can be installed with the popular recipe of
$ ./autogen.sh # If you got the sources directly from Git
$ ./configure
$ make install
This will put magit.el into /usr/local/share/emacs/site-lisp, where
Emacs should be able to find it. Then add
(require 'magit)
to your .emacs file.
* Getting started
To get started with Magit, open any file in a Git repository in Emacs
and run 'M-x magit-status'. Read the online help of magit-mode ('C-h
m' in the Magit buffer), make some changes to your files, and try to
commit them.
* Learning more
The Magit User Manual describes things with more words than the online
help. You can read it in Emacs with 'C-u C-h i magit.info' for
example, or on the web at
http://zagadka.vm.bytemark.co.uk/magit/magit.html
If you have questions, please use the mailing list at
http://groups.google.com/group/magit/
Magit's web home is currently at
http://zagadka.vm.bytemark.co.uk/magit/