git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Theodore Tso <tytso@mit.edu>
Date
Jul 2, 2007, 14:48 UTC
Message-ID
<20070702144800.GA4720@thunk.org>
In-Reply-To
<7vr6nrz9yx.fsf@assigned-by-dhcp.cox.net>
On Sun, Jul 01, 2007 at 09:49:10PM -0700, Junio C Hamano wrote:
Show 5 quoted lines
> The reason I personally use emacsclient is not about the
> start-up delay, but with the access to existing buffers,
> keyboard macros, Gnus buffers, ... IOW the access to the
> "session" while editing.  I suspect people with long running
> Emacs session use emacsclient for that reason.

Sure, but do you need access to existing buffers, keyboard, macros, etc., if you're simply firing up an emacs to handle a merge conflict? If the goal is just to run a merge application, then firing up a separate process makes a lot more sense.

One other thing which I just noticed is that emacs21's emacsclient does NOT support the -f or -e option. And a lot of people may still be using emacs21. So in any case, at the moment we are in fact using to fire up a separate process when using emerge or ediff. I suppose we could try testing to see if the user is running emacs21 or emacs22 if EDITOR==emacsclient, but there's no easy way of doing this short of doing something heavyweight such as firing up emacs and asking to eval some lisp that prints the value of emacs-version to stdout. And even then we would have to fix emerge to do the right thing when invoked via emacsclient. Yuck...

This still leaves us with the question about whether the following to fix ediff is acceptable:

   	  emacs --eval "(progn (defun ediff-write-merge-buffer () (let ((file ediff-merge-store-file)) (set-buffer ediff-buffer-C) (write-region (point-min) (point-max) file) (message \"Merge buffer saved in: %s\" file) (set-buffer-modified-p nil) (sit-for 1))) (setq ediff-quit-hook 'kill-emacs ediff-quit-merge-hook 'ediff-write-merge-buffer) (ediff-merge-files-with-ancestor \"$LOCAL\" \"$REMOTE\" \"$BASE\" nil \"$path\"))"

In my mind it's on the hairy edge. Alternatively we just never use ediff by default, and assume that either expert users can hack their .emacs.el file to have the right overrides will use ediff, or who are willing to put up with ediff's user-hostile approach to quitting an merge session.

						 -  Ted
Previous: Junio C HamanoNext: Junio C Hamano
Message 8 of 18 in “git-mergetool: add support for ediff”
  1. git-mergetool: add support for ediffSam Vilain, Jun 29, 2007
  2. Jason SewallJun 29, 2007
  3. Theodore TsoJun 29, 2007
  4. Theodore TsoJul 2, 2007
  5. Junio C HamanoJul 2, 2007
  6. Theodore TsoJul 2, 2007
  7. Junio C HamanoJul 2, 2007
  8. Theodore TsoJul 2, 2007
  9. Junio C HamanoJul 2, 2007
  10. Sam VilainJul 2, 2007
  11. Theodore TsoJul 2, 2007
  12. Theodore TsoJul 2, 2007
  13. Sam VilainJul 2, 2007
  14. Theodore TsoJul 3, 2007
  15. Sam VilainJul 3, 2007
  16. David KastrupJul 28, 2007
  17. Theodore TsoJul 29, 2007
  18. David KastrupJul 29, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.