Adds emacs to known mergers

[Edouard Gomez]

Thomas Arendsen Hein <thomas <at> intevation.de> writes:
> * Kevin Smith <yarcs <at> qualitycode.com> [20050701 01:29]:
> > Edouard Gomez wrote:
> > >Add emacs knowledge to hgmerge
> > 
> > If I understand this patch correctly, it will launch emacs if it exists, 
> > before tring $EDITOR. As a non-emacs user, I'm not really happy with 
> > that. Sure it's on my system, but I don't know how to use it.

Probably a multi user box, that is a case i didn't take care of with this patch, 

That's true that lot of editors can be installed on this kind of environments
and that doesn't imply all users use the same editor. For sure if hgmerge starts
vim for an emacs user, or even worse, emacs for a vim user... it can be a funny
situation :-)

> A solution might be to test if "$EDITOR" is some kind of emacs and
> only if it is, use it with the correct options.

There are lot of emacs clones out there, but not all support elisp... Knowing if
$EDITOR is "kind of emacs" can be made reliable only launching the application 
and looking at the version string.  If it's xemacs or GNU emacs then ediff might
be used. But for sure, if you don't like emacs because of its starting time, 
then this is no solution :-)

So a much weaker solution is to test if the EDITOR var matches the emacs string 
somehow (qemacs users are doomed). Another one is to simply have a switch to 
treat special `basename $EDITOR` values such as (x)emacs, (g)vim which all 
integrate some kind of 3 way mergers.

Note that this problem will also bite users for the already supported graphical
merging programs (tkmerge and the kde prog which i don't remember the name).
It's probably no problem for merge and diff3 because i'm sure users prefer
letting auto merging take place whenever it's possible :-)

I'd like to have opinions before posting another patch concerning this, because 
adding support for editors is kinda religious war among devs using X editor or Y
editor.

-- 
Edouard Gomez