On Sun, Jul 01, 2007 at 09:49:10PM -0700, Junio C Hamano wrote: > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
