Re: [PATCH] git-mergetool: add support for ediff

From: David Kastrup <dak@gnu.org>
Date: Jul 28, 2007, 09:22 UTC
Message-ID: <85hcno287w.fsf@lola.goethe.zz>
In-Reply-To: <20070703010955.GA5322@thunk.org>

[Picking up an old thread]

Theodore Tso <tytso@mit.edu> writes:

Show 22 quoted lines

> On Tue, Jul 03, 2007 at 11:19:49AM +1200, Sam Vilain wrote:
>
> Hmm, well, here's a way of fixing it.  (See attached, below.)  It
> adds a new command 'x', which when you hit it in the ediff control
> window, exits with a error status of '1', indicating that the merge
> has failed.  This is something which emerge, kdiff3, tkdiff, et. al
> all support; but which ediff doesn't.
>
>> I still don't really understand why having to save the merged buffer and
>> exit is such a huge issue.  Already I have to select "-t emerge" to get
>> emerge.  I would have thought it would be better to just make the other
>> mode available, and let the user figure it out.
>
> I'm just exploring alternatives.  Basically, it just seems
> interesting that ediff has a lot of nice features, but also has some
> incredibly user-hostile features.  The first time I tried using
> ediff, I indeed tried saving the buffer and exiting it.  That's when
> I discovered that after I changed the focus to the merge window and
> saved it, when I tried typing ^X^C, the exit failed with the error
> message "Attempt to delete a surrogate minibuffer frame".  That's
> the sort of thing that will cause non-elisp programmers to run
> screaming off into the distance.

Ted, I think you are somewhat missing the main audience here. The main audience are people who actually _use_ Emacs, and those will be comfortable with the concept "save to have changes persist, don't save if you don't want changes to persist, exit using C-x # or C-x C-c as appropriate". Basically, it would appear that you try figuring out how to make ediff appeal to non-Emacs users. But those would not have emacs/emacsclient in their EDITOR variable in the first place.

I have been bitten by mergetool calling emacs rather than emacsclient, resulting in a non-working merge (since the default directory was set differently from what the call expected due to my use of the desktop package), and mergetool afterwards assuming that the not-even-started merge was successful. A royal nuisance, and completely unworkable.

While it may be nice to have some Lisp preparation for people who don't want to touch or learn Emacs _except_ for using it for merging in git, I think we should first cater to people actually using Emacs already.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum