On Sat, Jul 28, 2007 at 11:35:40AM +0200, David Kastrup wrote: > David Kastrup <dak@xxxxxxx> writes: > > > If you use the desktop package, this means that you get a bear of a > > startup time while a _new_ instance of Emacs gets loaded against the > > wishes of the setup, and the command line parameters will be > > interpreted relatively to the last file restored into the desktop > > rather than the current directory (arguably a bug in the desktop > > package which I plan to fix eventually, but in the meantime the > > current package is farspread). > > I can't reproduce anything similar outside of mergetool, so it appears > more likely that mergetool is passing wrong relative file names. See my recent posting on this issue. The problem is that the desktop package fundamentally changes how emacs behaves when it starts up. And in order to fix it we will need to change git-mergetool to do an "emacs --version", parse the version number, and then start changing how it calls emacs (and if you *really* want to use emacsclient, whether it can use emacsclient) based on the version of emacs which is installed as the default for the user. It's going to be really messy, and fundamentally, emacs as used by people who are using the desktop package really wants to be the center of the universe, instead of something which gets called to run a "merge application". Testing to make sure this works on every single emacs version/variant, and every single user's weird-sh*t startup scripts isn't something I'm looking forward to. So I really am beginning to think the right answer is to give up on using git-mergetool to support anything other than basic emacs users (who just use emacs as an editor, what a concept), and for the H4rd C0re emacs l33t, they can use a contrib/git-mergetool.el that does everything inside emacs. Since these are the people who want emacs to be their desktop, their shell, *and* their window manager, they will probably be happier that way.... - 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
