This patch removes the runtime dependences on the cl package.
Luckily, there weren't too many of these.
From the GNU emacs lisp manual (Appendix D.1 coding conventions)
* Please don't require the `cl' package of Common Lisp extensions
at run time. Use of this package is optional, and it is not part
of the standard Emacs namespace. If your package loads `cl' at
run time, that could cause name clashes for users who don't use
that package.
However, there is no problem with using the `cl' package at
compile time, with `(eval-when-compile (require 'cl))'. That's
sufficient for using the macros in the `cl' package, because the
compiler expands them before generating the byte-code.
There's also the small matter that many of the function implementations
in cl, striving for the full generality of Common Lisp (much of which
is completely useless in Emacs), turn out to be horrible.
E.g., for a fun time, dig down through
(find-if pred list :from-end t),
and look at what it ACTUALLY does when you finish macroexpanding
everything. It tests *every* element of the list against the
predicate, not just the rightmost ones stopping when it finds the
first match. Once it determines the rightmost match, it then retains
NOT the element itself, but its *ordinal* position N, which then gets
used in (elt list N), meaning ANOTHER listwalk, just to get the
element back in order to return it. Nor is the byte-compiler anywhere
near smart enough to optimize this away (I'm not sure *any* compiler
would be...)
I'll grant cl has some useful macros in it, but it comes bundled with a
lot of crap and you need to be really careful about what you use. For
many things, you're better off rolling your own functionality using
the standard routines available (e.g., while, mapcar, and reverse are
all written directly in C).
And you most definitely do NOT want to be foisting the crap on
everybody else, hence the need to keep it out of the runtime.
Meanwhile, here's The Patch:
Modified magit.el
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:
Here, have some docstrings:
(...it being something of a show-stopper for newbies when they want to
find out what a given keystroke will do, they hit ^Hk [or ^Hf or ^Hv],
and nothing useful comes out...)
If you do
. magit-status on repository .../x
. V (magit-show-branches)
. magit-status on repository .../y
. V (magit-show-branches)
you get the branch listing for repository .../x
Also, as a side issue, functionality of a buffer should not be
keyed off of the buffer name (in this case, renaming the buffer
should not change what V or g does).
The following patch deals with both of these.
They all apply to hunk, commit and diff that are in
status, stash, log, reflog, diff and wazzup buffers.
Signed-off-by: Rémi Vanicat <vanicat@debian.org>
magit's interactive rebase feature tries to start the server even if
it is already running. If it is already running then Emacs asks
whether or not it should destroy existing clients. This is fatal if
the frame magit is running in was created by emacsclient
itself (e.g. Emacs is running in the background with "--daemon"), so
the user has to answer "no".
This question can be avoided if the server is only startet if it isn't
already running.
The following functions are available from the branch list (which in
turn is made read-only):
- Checking out the branch in the current line
- Deleting the branch in the current line (prefix forces deletion even
if not merged into current branch); works on both local and remote
branches
- Manual and automatic merges of the branch in the current line into
the current branch
- Quitting the branch list
Includes updated documentation.
If you have a local tracking branch, e.g. called 'test', and the
remote branch name is different than test (e.g. 'somwhere/master')
then the commands for retrieving the unpulled and unpushed commits was
calling "git log test..somwehere/test" which may or may not exist.
Add a modest rpm .spec file and ensure that it's autoconf'd to keep
step with the release version number.
Ignore the generated .spec file, but ensure it's distributed with any
tarballs.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Makefile.am uses $builddir, which isn't available in older (<= 1.9)
versions of automake. Declare this requirement explictly in
configure.acy.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
The autoconf/automake files now honour --with-site-start to allow
selection of the directory where automatically sourced elisp files are
stored. The original default is retained.
This switch makes support of non-debian systems easier. RHEL5, for
example, places these files in /usr/emacs/site-lisp/site-start.d/.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
