Theodore Tso [off-list ref] writes:
Unfortunately, it's not enough. Ediff doesn't have an "abort" command
which returns a non-zero exit status, and when you use the "quit"
command, it asks you a series of obnoxious questions:
...
Alternatively, we could patch around the problem. The following emacs
lisp code fixes the ediff issues:
But that would be changing the behaviour globally, and not
limited to the particular session invoked from git-mergetool,
wouldn't it? If that is the case it would be a hard sell to
Emacs users, especially the ones that keep their Emacs running
forever and have emacsclient as their EDITOR, I would think.
On Sun, Jul 01, 2007 at 07:32:59PM -0700, Junio C Hamano wrote:
Theodore Tso [off-list ref] writes:
quoted
Unfortunately, it's not enough. Ediff doesn't have an "abort" command
which returns a non-zero exit status, and when you use the "quit"
command, it asks you a series of obnoxious questions:
...
Alternatively, we could patch around the problem. The following emacs
lisp code fixes the ediff issues:
But that would be changing the behaviour globally, and not
limited to the particular session invoked from git-mergetool,
wouldn't it? If that is the case it would be a hard sell to
Emacs users, especially the ones that keep their Emacs running
forever and have emacsclient as their EDITOR, I would think.
The emacs lisp code I gave there was the minimal necessary so it
could be passed on the command-line; I was trying to keep it small.
Obviously, the patch that would have to get sent to the ediff folks
would have to be much more generalized --- in fact, probably the right
thing to do is to send a full patch that actually implemented
ediff-merge-files-command and ediff-merge-files-with-ancestoers-commands.
As far as people using emacsclient as their editor, it would be simple
enough to have the emacs lisp code test to see if
server-buffer-clients is non-nill; if it is, then we know that this
merge request was trigered by emacsclient, and so (server-done) should
be called instead of (kill-emacs). Emerge does not do this; arguably
this is a bug in emerge.
The other way we could deal with this problem is to fire up a separate
emacs even if EDITOR is emacsclient, on the theory that
EDITOR=emacsclient meants that the user prefers emacs, but it doesn't
necessarily mean that we have to *use* emacsclient, especially when
emerge currently doesn't DTRT with emacsclient.
One thing that did cross my mind is that we could put code which
patched ediff.el and emerge.el in /usr/share/git/lisp/... and then
passed called emacs with something like this "emacs -l
$sharedir/lisp/ediff-patches.el ...". But this implies packaging
emacs lisp files with git, and I'm not at ALL sure we want to go
there. Personally, I still like kdiff3 as my personal favorite
mergetool, and given that emacs starts up pretty fast these days, I've
given up on emacsclient, but I know there are certainly people who use
them.
(Mmmm...., I just pulled down an early emacs 23 snapshot with Xft
support enabled, so I can enjoy the anti-aliased font goodness. Even
with all of the Gtk and Xft bloat, the emacs 23 snapshot is still
quick snappy to fire up.)
- Ted