Theodore Tso <tytso@xxxxxxx> writes: > On Sat, Jul 28, 2007 at 11:22:43AM +0200, David Kastrup wrote: >> 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. > > Emacsclient is a completely different problem, or at least adds a > whole new dimention, compared to the ediff/emerge issue. You can't > run either emerge or ediff using the emacsclient in emacs21, since > it lacks support for either the -e or the -f command-line option. If the user asks for it, we should try giving it to him. If Emacsclient bombs out because of a non-understood option, one can still fall back to calling a separate Emacs. > All you can do in emacs21 when using eamcsclient is to request emacs > to edit a file. Yes, but emacsclient --version returns a version string, and emacsclient will exit with an error if it can't get to understand the command line options or to talk with Emacs. So there are reasonably ways to notice when to fallback. > One of the problems with emacs is that it is so customizable that > people can set up emacs in such a way that different ways of > launching emacs may lead to surprises, thanks to their .emacs21. > This makes supporting emacs based merging clients to be highly > problematic. Use of the desktop package is one way in which things > can be quite surprising. Worse yet, the desktop package is only in > emacs22 and up. The desktop package has already been in Emacs 21, so it is not exactly a new problem but has been round for more than 7 years. > (And emacs 22 was *just* released, not all that long ago; many > people may still be using emacs21). So if we use emacs --no-desktop > to disable the desktop package, it will cause emacs21 to complain > about an unknown option. Joy. Correct: the --no-desktop option is new. > Which means that to avoid running into problems with emacs22 users > who are using the desktop package, git-mergetool is going to have to > find out in advance whether emacs21 or emacs22 (or an emacs > development 23.0.0 snapshot) is in use; on a debian system you can > have 3 or 4 emacs installed simultaneously. What fun. $EDITOR --version > In any case, the main issue is that there is an emerging (sorry) > standard about how merge tools are supposed to work, in terms of > being able to support 2-way or 3-way merges, about being able to > specify which file (and which file only, in the best case) should be > used as the output file as the result of the merge, and about how > tools can signal either a successful merge, or a request by the user > to abort the merge becuase things didn't work out for one reason or > another. > > The problem is that ediff doesn't really fit this model. Emacs is an editor. If we can't make an editor fit into merge resolution, we have a design problem. It is a matter of convenience that the editor is called with some initial files and something like ediff-whatever, but the end result clearly should be that the user writes the file if he wants changes to persist, and doesn't if doesn't. > For people who really want to live their life in emacs, and using > emacs as their desktop (not for me, but maybe for some folks), maybe > it would be better for those folks to simply build a > git-mergetool.el that ran 100% in emacs, instead of trying to shift > back and forth between the command-line and emacs, would make > everyone happier. Right now git-mergetool needs to ask questions > about the disposition of symlinks, permission changes, etc. If it > is done as a git-mergetool.el which is tied into git.el and ediff, > it could be a lot more seamless. But this is no reason not to fix the currently broken behavior. If you insist that "emerge" or "ediff" is _not_ to be used as an editor, but rather as a special-purpose mergetool for the sake of git, then the only logical conclusion can be to call it with "-q", bypassing any user initialization. I believe this would be a mistake at least when $EDITOR points to Emacs, because this means the user is used to using Emacs/Emacsclient as _editor_, and anything else would be _confusing_. >> 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. > > Catering to the hard-core Emacs folks is *hard*. Saving a desktop session is not hard-core. Using emacsclient is not hard-core. Those are standard, basic, use cases. > I knew someone who had PDP-10 assembly language in their .emacs.el > file, and one day his custom emacs extension worked again when he > started playing with the KLH10 PDP-10 emulator, and reused his > .emacs.el startup file there.... Can we get another strawman a bit closer to the main road, please? > Of course, at some level folks like that will always need to fend > for themselves. Yes. I am not talking about people breaking things by code of their own. I am talking about a _standard_ setup being broken by git. > As I said earlier, I don't have a huge objection to support ediff in > some degraded mode (I think the UI is ghastly bad), if users > explicitly request it, but I would *not* want to make it the default > and spring it on some unsuspecting user. Quite frankly, right now > the KDE and GNOME tools are way better either emerge or ediff, so > they are only really useful as a default in the terminal-only case. Again, you fall into the trap of not allowing others to have a life and Emacs outside of git's preconceptions. emerge and ediff might be worse for people who would not use Emacs for anything but merging. But one advantage of Emacs is that I can look at all sorts of other files and buffers and information sources _while_ I am merging, and declare the merge finished when _I_ want it (signaled by exiting either Emacs or Emacsclient), not when some arbitrary command thinks it finished. Emacs is one of the most flexible tools ever. Disallowing any editing use not foreseen and sanctioned by git-mergetool is _always_ going to lead to trouble. If you do _anything_ like this, you _must_ call Emacs -q in order to omit _any_ user initializations you did not foresee. But this will also kill user-specific major modes which he might want to use for visualizing files. It will be less onerous than having all hell break lose because you can't cater for even standard initializations or setup, but it will still be a nuisance. So please don't try crippling Emacs into a git-only tool. Call it with the files in question, give it an appropriate initial command to work with if possible, and leave the rest to the user. He will save and finish, or not save and finish, which is the way of an editor to communicate with its environment. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
