New Magit Commit mode is opening new instance of Emacs to write commit message in OS X/Emacs #862

Closed
jasonm23 opened this Issue Sep 8, 2013 · 93 comments

Comments

Projects
None yet
@jasonm23

jasonm23 commented Sep 8, 2013

Starting today, Magit's overhauled commit process is invoking a completely new instance of Emacs (osx GUI) when starting the commit message process.

No problems in Terminal mode (unsurprisingly)

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 8, 2013

Unable to replicate again after restarting Emacs, closing.

jasonm23 commented Sep 8, 2013

Unable to replicate again after restarting Emacs, closing.

@jasonm23 jasonm23 closed this Sep 8, 2013

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 12, 2013

Replicates after Emacs is open for a few hours, haven't yet discovered the trigger. Assume this is related to the new use of git-commit-mode

Replicates after Emacs is open for a few hours, haven't yet discovered the trigger. Assume this is related to the new use of git-commit-mode

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 14, 2013

Owner

I doubt that has anything to do with Magit.

Check if the server is still running and whether you can connect using /path/to/emacsclient foobar.

Owner

tarsius commented Sep 14, 2013

I doubt that has anything to do with Magit.

Check if the server is still running and whether you can connect using /path/to/emacsclient foobar.

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 15, 2013

Why would magit be calling emacsclient?

While already in Emacs, we need a new buffer not a call to emacsclient.

Why would magit be calling emacsclient?

While already in Emacs, we need a new buffer not a call to emacsclient.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 15, 2013

Owner

Why would magit be calling emacsclient?

Emacs (Magit) isn't, Git is. git commit is most powerful without -m and without a message on stdin. Also thinking of this as some kind of callback might help.

That is a bit of a controversial issue around here, to say the least... let me put it this way: it has advantages but also an inherent drawback (not everyone has client-server interaction setup appropriately and we have to work around that, which might not always work) and there are also some temporary but serious issues.

Given these disadvantages the advantages are not yet visible and more on the conceptional side. Basically we don't have to duplicate git functionality and get new git functionality for free. E.g. We get git's own hooks for free. Git removes the message file when appropriate, and doesn't when not appropriate etc.

If you look around there are quiet a few issues touching on this topic (see https://github.com/magit/magit/issues?milestone=10&state=open).

Owner

tarsius commented Sep 15, 2013

Why would magit be calling emacsclient?

Emacs (Magit) isn't, Git is. git commit is most powerful without -m and without a message on stdin. Also thinking of this as some kind of callback might help.

That is a bit of a controversial issue around here, to say the least... let me put it this way: it has advantages but also an inherent drawback (not everyone has client-server interaction setup appropriately and we have to work around that, which might not always work) and there are also some temporary but serious issues.

Given these disadvantages the advantages are not yet visible and more on the conceptional side. Basically we don't have to duplicate git functionality and get new git functionality for free. E.g. We get git's own hooks for free. Git removes the message file when appropriate, and doesn't when not appropriate etc.

If you look around there are quiet a few issues touching on this topic (see https://github.com/magit/magit/issues?milestone=10&state=open).

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 15, 2013

Simply handing off to git isn't why I use Magit, I expect it to wrap & enhance functionality, and git provides you relatively simple ways to do that.

The only reason I can think of to use the basic git committing view is the status list. However, Magit was/is already providing that.

Since this issue manifested, I've just dropped out of Emacs/Magit to the shell and run all my git ops from there.

This feels like a cop out to be honest.

There are many ways to improve commit mode (templates?! But ya snippet has us covered there.)

What real benefit are you adding with this one? Please don't get me wrong, I (previously) loved and recommended Magit, but I see no merit in this decision.

I hope you're open to discussion on this, I understand if you've reached a "controversy fatigue" point on this, but there is strong opinion on this for a reason.

Simply handing off to git isn't why I use Magit, I expect it to wrap & enhance functionality, and git provides you relatively simple ways to do that.

The only reason I can think of to use the basic git committing view is the status list. However, Magit was/is already providing that.

Since this issue manifested, I've just dropped out of Emacs/Magit to the shell and run all my git ops from there.

This feels like a cop out to be honest.

There are many ways to improve commit mode (templates?! But ya snippet has us covered there.)

What real benefit are you adding with this one? Please don't get me wrong, I (previously) loved and recommended Magit, but I see no merit in this decision.

I hope you're open to discussion on this, I understand if you've reached a "controversy fatigue" point on this, but there is strong opinion on this for a reason.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 15, 2013

Owner

I've just dropped out of Emacs/Magit

Clone the repository and checkout branch old-committing instead.

  1. I am working on (a) fixing the new workflow and (b) adding the old one back as an option.
  2. #830

Again sorry to have caused problems, many things have contributed to this, and various things could have been handled differently and faster. I have indeed reached a "controversy fatigue" but that isn't because I don't understand the justified reservations people are having, it's because what caused this mistake in the first place is that I didn't listen to my own intuition and instead let people who had obviously given it less though convince me that I was being over cautious. I am not going to do that here again.

Please don't get me wrong, I (previously) loved and recommended Magit, but I see no merit in this decision.

Given the history of this, I am having trouble not to. You have chosen to use the development of some software, and instead of putting in a little effort to determine a version that works you see the need to tell the main developer that you stopped "loving and recommending" it, basically that I destroyed it for you. If you love some old version, then just use that until the development version has caught up.

I have implemented tones of improvements and made one big mistake due to overwhelming pressure and probably also haven't handled the breakage as good as I could have. But since I have implemented ~80-100 new feature, many of which have been requested years ago and for which I personally have no use for, all while cleaning up the code base to enable future improvements, I am insulted that you see the need to mention that it "[doesn't even support] templates?!". If you miss that feature open a feature request for it. By the way the new commit mode actually enables to use of githooks for this purpose, I have hinted at that above.

This gives you an idea of how much I have done: https://github.com/magit/magit/pulse/monthly

What real benefit are you adding with this one?

I have already addressed that. We can take full benefit of git functionality. And I also said that I can understand that this isn't obvious to the casual user yet, because the good stuff is hidden behind ongoing breakage.


Back to the issue. I think that the emacs server for some reason dies on your machine. If you provide the information I have asked for, we can go past speculations. Is that actually the only deal breaker for you? If that is so and it actually turns out that your system is hosed, then it is quiet unfair to blame it on Magit, because it would basically mean that you don't want us to take benefit of some integral Emacs functionality because you cannot be bothered to investigate why that isn't working on your machine.

Owner

tarsius commented Sep 15, 2013

I've just dropped out of Emacs/Magit

Clone the repository and checkout branch old-committing instead.

  1. I am working on (a) fixing the new workflow and (b) adding the old one back as an option.
  2. #830

Again sorry to have caused problems, many things have contributed to this, and various things could have been handled differently and faster. I have indeed reached a "controversy fatigue" but that isn't because I don't understand the justified reservations people are having, it's because what caused this mistake in the first place is that I didn't listen to my own intuition and instead let people who had obviously given it less though convince me that I was being over cautious. I am not going to do that here again.

Please don't get me wrong, I (previously) loved and recommended Magit, but I see no merit in this decision.

Given the history of this, I am having trouble not to. You have chosen to use the development of some software, and instead of putting in a little effort to determine a version that works you see the need to tell the main developer that you stopped "loving and recommending" it, basically that I destroyed it for you. If you love some old version, then just use that until the development version has caught up.

I have implemented tones of improvements and made one big mistake due to overwhelming pressure and probably also haven't handled the breakage as good as I could have. But since I have implemented ~80-100 new feature, many of which have been requested years ago and for which I personally have no use for, all while cleaning up the code base to enable future improvements, I am insulted that you see the need to mention that it "[doesn't even support] templates?!". If you miss that feature open a feature request for it. By the way the new commit mode actually enables to use of githooks for this purpose, I have hinted at that above.

This gives you an idea of how much I have done: https://github.com/magit/magit/pulse/monthly

What real benefit are you adding with this one?

I have already addressed that. We can take full benefit of git functionality. And I also said that I can understand that this isn't obvious to the casual user yet, because the good stuff is hidden behind ongoing breakage.


Back to the issue. I think that the emacs server for some reason dies on your machine. If you provide the information I have asked for, we can go past speculations. Is that actually the only deal breaker for you? If that is so and it actually turns out that your system is hosed, then it is quiet unfair to blame it on Magit, because it would basically mean that you don't want us to take benefit of some integral Emacs functionality because you cannot be bothered to investigate why that isn't working on your machine.

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 15, 2013

Sorry to come off as a bit of an ass, I just wanted to make my feelings heard, I'm more than happy to get Emacs client functionality fixed in the short term but I really don't like the way the feature was implented, and that's all I wanted to get across.

I completely understand, and I really appreciate the time you've taken to respond.

I will follow up shortly.

Sorry to come off as a bit of an ass, I just wanted to make my feelings heard, I'm more than happy to get Emacs client functionality fixed in the short term but I really don't like the way the feature was implented, and that's all I wanted to get across.

I completely understand, and I really appreciate the time you've taken to respond.

I will follow up shortly.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 15, 2013

Owner

Thanks, all forgiven and forgotten. Now lets try to fix this particular issue.

Since it is "a bit" late here I will likely not work on this any more before tomorrow.

Owner

tarsius commented Sep 15, 2013

Thanks, all forgiven and forgotten. Now lets try to fix this particular issue.

Since it is "a bit" late here I will likely not work on this any more before tomorrow.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 15, 2013

Owner

By the way, nice avatar :-)

Owner

tarsius commented Sep 15, 2013

By the way, nice avatar :-)

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 15, 2013

Cheers. You to.

The problem of development version being in production is really a MELPA issue. I'll reconfigure.

Again apologies for coming on strong, my assumptions have all been shown erroneous. I'm glad to hear that you're working on turning this around.

Cheers. You to.

The problem of development version being in production is really a MELPA issue. I'll reconfigure.

Again apologies for coming on strong, my assumptions have all been shown erroneous. I'm glad to hear that you're working on turning this around.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 15, 2013

Owner

The problem of development version being in production is really a MELPA issue.

Well to be honest I/we also have to take some blame for that. We missed our chance to make a timely release. But that will change too (much more frequent minor and subminor releases after the next major release).

Again apologies for coming on strong,

It's all good. You hit a sore spot, and so I reacted strongly too. Sorry about that.

Owner

tarsius commented Sep 15, 2013

The problem of development version being in production is really a MELPA issue.

Well to be honest I/we also have to take some blame for that. We missed our chance to make a timely release. But that will change too (much more frequent minor and subminor releases after the next major release).

Again apologies for coming on strong,

It's all good. You hit a sore spot, and so I reacted strongly too. Sorry about that.

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 16, 2013

Appears that Emacs server dies / hangs on my build (24.3.1 / Carbon/EmacsMacPort) which is why it's happening intermittently, I don't think I can do much about that, as I rely on other things in this build (SVG support primarily.)

Appears that Emacs server dies / hangs on my build (24.3.1 / Carbon/EmacsMacPort) which is why it's happening intermittently, I don't think I can do much about that, as I rely on other things in this build (SVG support primarily.)

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 16, 2013

I'll try and spin builds on different boxes (ie. Cocoa emacs, and a build on Debian/X/GTk) - expect I'll have time to get those set up during the week

I'll try and spin builds on different boxes (ie. Cocoa emacs, and a build on Debian/X/GTk) - expect I'll have time to get those set up during the week

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 16, 2013

Owner

That sucks. One way to deal with that would be to force the use of the "fallback editor" by explicitly setting magit-emacsclient-executable to nil. However the current implementation of that fallback is not very good. It's good enough for occational use with tramp, but if you have to always use it then its limitations will be rather frustrating. I am working on a better fallback, but I won't make any promises when that is done. It might be done soon, but I already said that two weeks ago. :-/

The build you are using is not the official version from GNU, right? It's some port with additional niceties, like better toolkit integration, isn't it? I strongly recommend against using that. You will find other people giving the same advice if you google for it.

The reason why you should not use anything but the official version is that with these ports you don't have anybody to goto with the kind of problem you are experience now. So instead of verifying that you cannot reproduce this on Debian, I would recommend you instead install the official version on OS X. I have an old mac that I hardly ever use - on that I use homebrew to install Emacs and a bunch of other things, might be an option for you too.

Owner

tarsius commented Sep 16, 2013

That sucks. One way to deal with that would be to force the use of the "fallback editor" by explicitly setting magit-emacsclient-executable to nil. However the current implementation of that fallback is not very good. It's good enough for occational use with tramp, but if you have to always use it then its limitations will be rather frustrating. I am working on a better fallback, but I won't make any promises when that is done. It might be done soon, but I already said that two weeks ago. :-/

The build you are using is not the official version from GNU, right? It's some port with additional niceties, like better toolkit integration, isn't it? I strongly recommend against using that. You will find other people giving the same advice if you google for it.

The reason why you should not use anything but the official version is that with these ports you don't have anybody to goto with the kind of problem you are experience now. So instead of verifying that you cannot reproduce this on Debian, I would recommend you instead install the official version on OS X. I have an old mac that I hardly ever use - on that I use homebrew to install Emacs and a bunch of other things, might be an option for you too.

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 17, 2013

I'm pretty intimate with the patches involved, and they're isolated from things like the server. They provide a terminal, macterm to replace the cocoa nsterm.

I think the problem is more likely due to the fact I'm building from snapshots, and patching those.

I'm pretty intimate with the patches involved, and they're isolated from things like the server. They provide a terminal, macterm to replace the cocoa nsterm.

I think the problem is more likely due to the fact I'm building from snapshots, and patching those.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 17, 2013

Owner

Oh in that case I will send users having problems with these ports to you from now on - just kidding :-)

In that case, yes, try with a stable version.

Owner

tarsius commented Sep 17, 2013

Oh in that case I will send users having problems with these ports to you from now on - just kidding :-)

In that case, yes, try with a stable version.

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 17, 2013

Oh in that case I will send users having problems with these ports to you from now on - just kidding :-)

aiee!

In that case, yes, try with a stable version.

Will do 👍

Oh in that case I will send users having problems with these ports to you from now on - just kidding :-)

aiee!

In that case, yes, try with a stable version.

Will do 👍

@warner

This comment has been minimized.

Show comment Hide comment
@warner

warner Sep 19, 2013

Contributor

In case it helps, I had a similar problem. I had compiled my own copy of Emacs, on OS-X, and launched it by double-clicking ~/Applications/Emacs.app . When magit/git ran, I think it looked around for an "emacsclient", found the old system-installed one in /usr/bin/emacsclient, deduced that it wasn't related to the ~/Applications/Emacs.app/Contents/MacOS/Emacs that magit was running under, and went to the fallback case (which launches a new copy of emacs for the commit message).

I fixed it by symlinking Emacs.app/Contents/MacOS/bin/emacsclient into a directory on my $PATH. Now I get the server-based commit message editor as expected.

Contributor

warner commented Sep 19, 2013

In case it helps, I had a similar problem. I had compiled my own copy of Emacs, on OS-X, and launched it by double-clicking ~/Applications/Emacs.app . When magit/git ran, I think it looked around for an "emacsclient", found the old system-installed one in /usr/bin/emacsclient, deduced that it wasn't related to the ~/Applications/Emacs.app/Contents/MacOS/Emacs that magit was running under, and went to the fallback case (which launches a new copy of emacs for the commit message).

I fixed it by symlinking Emacs.app/Contents/MacOS/bin/emacsclient into a directory on my $PATH. Now I get the server-based commit message editor as expected.

@PureAbstract

This comment has been minimized.

Show comment Hide comment
@PureAbstract

PureAbstract Sep 19, 2013

Contributor

I saw something similar to this with magit running under Aquamacs on OS X.

In my case, it was related to the logic used to initialise magit-emacsclient-executable. Part of that logic looks in invocation-directory for the emacsclient binary; in the case of Aquamacs, that actually lives in (concat invocation-directory "/bin") - and so the magic-emacsclient-executable logic doesn't find it. I worked around it by just customising the variable. (FWIW, things used to work fine prior to the introduction of this logic, when magit just used the GIT_EDITOR value I'd set previously).

I've just pushed a patch that works for me, with my setup - PureAbstract/magit@31a59ad - although as-written, this probably won't help @warner (since I check based on (featurep 'aquamacs) rather than (e.g.) (eq system-type 'darwin), but I imagine that logic can be extended relatively easily for other environments that don't keep emacsclient in the same location as the emacs executable.

@warner - I'd suggest you try removing your symlink, customizing magic-emacsclient-executable to the actual path of your emacsclient and see how that works. If so, it'd be perhaps be useful to see what that path is - and how it relates to your invocation-directory.

Contributor

PureAbstract commented Sep 19, 2013

I saw something similar to this with magit running under Aquamacs on OS X.

In my case, it was related to the logic used to initialise magit-emacsclient-executable. Part of that logic looks in invocation-directory for the emacsclient binary; in the case of Aquamacs, that actually lives in (concat invocation-directory "/bin") - and so the magic-emacsclient-executable logic doesn't find it. I worked around it by just customising the variable. (FWIW, things used to work fine prior to the introduction of this logic, when magit just used the GIT_EDITOR value I'd set previously).

I've just pushed a patch that works for me, with my setup - PureAbstract/magit@31a59ad - although as-written, this probably won't help @warner (since I check based on (featurep 'aquamacs) rather than (e.g.) (eq system-type 'darwin), but I imagine that logic can be extended relatively easily for other environments that don't keep emacsclient in the same location as the emacs executable.

@warner - I'd suggest you try removing your symlink, customizing magic-emacsclient-executable to the actual path of your emacsclient and see how that works. If so, it'd be perhaps be useful to see what that path is - and how it relates to your invocation-directory.

@warner

This comment has been minimized.

Show comment Hide comment
@warner

warner Sep 20, 2013

Contributor

ah, I see what you mean. Rather than a platform-specific check, maybe it'd make sense to always look in both the directory where emacs lives, and also in a bin/ subdirectory of that directory? I think that'd handle Aquamacs and regular Emacs on OS-X, and wouldn't hurt anything on unixy systems (that don't even have a /usr/bin/bin/).

Contributor

warner commented Sep 20, 2013

ah, I see what you mean. Rather than a platform-specific check, maybe it'd make sense to always look in both the directory where emacs lives, and also in a bin/ subdirectory of that directory? I think that'd handle Aquamacs and regular Emacs on OS-X, and wouldn't hurt anything on unixy systems (that don't even have a /usr/bin/bin/).

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 20, 2013

Owner

directory where emacs lives, and also in a bin/ subdirectory of that directory

wtf? a bin directory inside a bin directory? Yes, yes I know, some kind of filesystem-inside-an-icon stuff, but still :-)

Owner

tarsius commented Sep 20, 2013

directory where emacs lives, and also in a bin/ subdirectory of that directory

wtf? a bin directory inside a bin directory? Yes, yes I know, some kind of filesystem-inside-an-icon stuff, but still :-)

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 20, 2013

Owner

So the main executable is at the top-level of the "application directory, displayed as a single file" and all other executables are in a subdirectory?

Owner

tarsius commented Sep 20, 2013

So the main executable is at the top-level of the "application directory, displayed as a single file" and all other executables are in a subdirectory?

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 20, 2013

Owner

PATH="/path/to/Emacs.app:/path/to/Emacs.app/bin:$PATH"

Owner

tarsius commented Sep 20, 2013

PATH="/path/to/Emacs.app:/path/to/Emacs.app/bin:$PATH"

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 20, 2013

Owner

When things started falling apart I was surprised that not only Windows users had problems but also OS X users. I can see now why that is so :-/

Owner

tarsius commented Sep 20, 2013

When things started falling apart I was surprised that not only Windows users had problems but also OS X users. I can see now why that is so :-/

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 20, 2013

It's:

/Applications/Emacs.app/Contents/MacOS/

Typically, all executables will be in there for that App package.

It's:

/Applications/Emacs.app/Contents/MacOS/

Typically, all executables will be in there for that App package.

@PureAbstract

This comment has been minimized.

Show comment Hide comment
@PureAbstract

PureAbstract Sep 20, 2013

Contributor

Not quite... the 'application directory' is /Applications/Aquamacs.app/ - and that's the thing that a user "runs" (yes, you "run" the directory.
The actual Aquamacs executable is at /Applications/Aquamacs.app/Contents/MacOS/Aquamacs (so invocation-directory is /Applications/Aquamacs.app/Contents/MacOS/.
Meanwhile, then emacsclient executable actually lives at /Applications/Aquamacs.app/Contents/MacOS/bin/emacsclient

I've had $GIT_EDITOR (and $EDITOR and $VISUAL) set to /Applications/Aquamacs.app/Contents/MacOS/bin/emacsclient for I don't-know-how-long - and that always worked fine (and still does for anything I run from a shell). Things started going wrong when magit started to try and outsmart me... ;)

Contributor

PureAbstract commented Sep 20, 2013

Not quite... the 'application directory' is /Applications/Aquamacs.app/ - and that's the thing that a user "runs" (yes, you "run" the directory.
The actual Aquamacs executable is at /Applications/Aquamacs.app/Contents/MacOS/Aquamacs (so invocation-directory is /Applications/Aquamacs.app/Contents/MacOS/.
Meanwhile, then emacsclient executable actually lives at /Applications/Aquamacs.app/Contents/MacOS/bin/emacsclient

I've had $GIT_EDITOR (and $EDITOR and $VISUAL) set to /Applications/Aquamacs.app/Contents/MacOS/bin/emacsclient for I don't-know-how-long - and that always worked fine (and still does for anything I run from a shell). Things started going wrong when magit started to try and outsmart me... ;)

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 20, 2013

Owner

@PureAbstract Sorry that by fixing it for users who had not taken the appropriate steps I have broken it for you, who actually knows what you are doing and took the time to do it...

Owner

tarsius commented Sep 20, 2013

@PureAbstract Sorry that by fixing it for users who had not taken the appropriate steps I have broken it for you, who actually knows what you are doing and took the time to do it...

@PureAbstract

This comment has been minimized.

Show comment Hide comment
@PureAbstract

PureAbstract Sep 20, 2013

Contributor

@tarsius No big deal - it took me a little while to figure out what had happened, and then I just customized the setting and forgot about it. (Although I seem to recall I thought about the logic when I posted the fix for the let binding in there a little while ago) All my patch does is try and make magit better at helping out those who haven't got things set up correctly.

(although I'm wondering if maybe this is contributing to the problems some windows users are having - I don't use Windows if I can avoid it - but I have a vague recollection of something called winclient.exe rather than emacsclient.exe)

Contributor

PureAbstract commented Sep 20, 2013

@tarsius No big deal - it took me a little while to figure out what had happened, and then I just customized the setting and forgot about it. (Although I seem to recall I thought about the logic when I posted the fix for the let binding in there a little while ago) All my patch does is try and make magit better at helping out those who haven't got things set up correctly.

(although I'm wondering if maybe this is contributing to the problems some windows users are having - I don't use Windows if I can avoid it - but I have a vague recollection of something called winclient.exe rather than emacsclient.exe)

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 20, 2013

@PureAbstract just a quick FYI the folder itself isn't executed it's 'opened' then the info.plist identifies which file in Contents/MacOS is executed.

@PureAbstract just a quick FYI the folder itself isn't executed it's 'opened' then the info.plist identifies which file in Contents/MacOS is executed.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Sep 20, 2013

Owner

Is aquaemacs actually doing a non-standard thing by putting emacsclient in a different directory than emacs? Or is that a common pattern?

Owner

tarsius commented Sep 20, 2013

Is aquaemacs actually doing a non-standard thing by putting emacsclient in a different directory than emacs? Or is that a common pattern?

@PureAbstract

This comment has been minimized.

Show comment Hide comment
@PureAbstract

PureAbstract Sep 20, 2013

Contributor

@jasonm23 Yeah, I agree what's happening under the hood (having written a few of these things ;-) - but from the user's POV they "run" what is actually a directory (i.e. they double click on /Applications/Aquamacs.app). Much as if you type open /Applications/Aquamacs.app from the command line).

Contributor

PureAbstract commented Sep 20, 2013

@jasonm23 Yeah, I agree what's happening under the hood (having written a few of these things ;-) - but from the user's POV they "run" what is actually a directory (i.e. they double click on /Applications/Aquamacs.app). Much as if you type open /Applications/Aquamacs.app from the command line).

@warner

This comment has been minimized.

Show comment Hide comment
@warner

warner Sep 20, 2013

Contributor

I think the "look inside an .app for a .plist and follow its instructions" is an OS-X Finder -specific thing, used by both the finder (when you double-click an icon) and by the OS-X CLI /usr/bin/open tool.

The layout of having emacs live in *.app/Contents/MacOS/, but all other bin-things in *.app/Contents/MacOS/bin/, seems to be specific to emacs (both the AquaMacs fork and the upstream FSF emacs-24.3 tarball when configured with --with-ns).

Contributor

warner commented Sep 20, 2013

I think the "look inside an .app for a .plist and follow its instructions" is an OS-X Finder -specific thing, used by both the finder (when you double-click an icon) and by the OS-X CLI /usr/bin/open tool.

The layout of having emacs live in *.app/Contents/MacOS/, but all other bin-things in *.app/Contents/MacOS/bin/, seems to be specific to emacs (both the AquaMacs fork and the upstream FSF emacs-24.3 tarball when configured with --with-ns).

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 20, 2013

@PureAbstract

Much as if you type open /Applications/Aquamacs.app from the command line).

That was my point really... instead of just typing /Applications/Aquamacs.app, the use of open is required.

@tarsius

Is aquaemacs actually doing a non-standard thing by putting emacsclient in a different directory than emacs? Or is that a common pattern?

It's an optional thing, usually apps with a bunch of CLI tools will keep them in /usr/local/... or alternatives ( eg. /opt/...) and just have the main executable in the App folder

@PureAbstract

Much as if you type open /Applications/Aquamacs.app from the command line).

That was my point really... instead of just typing /Applications/Aquamacs.app, the use of open is required.

@tarsius

Is aquaemacs actually doing a non-standard thing by putting emacsclient in a different directory than emacs? Or is that a common pattern?

It's an optional thing, usually apps with a bunch of CLI tools will keep them in /usr/local/... or alternatives ( eg. /opt/...) and just have the main executable in the App folder

@warner

This comment has been minimized.

Show comment Hide comment
@warner

warner Sep 20, 2013

Contributor

Oh, and I don't think we need to set $PATH to include both directories: just look in both when trying to compute the full path to emacsclient. I believe (but could be wrong) that $PATH doesn't need to change at all: it's ok if emacsclient couldn't find itself on the $PATH that it receives.

Contributor

warner commented Sep 20, 2013

Oh, and I don't think we need to set $PATH to include both directories: just look in both when trying to compute the full path to emacsclient. I believe (but could be wrong) that $PATH doesn't need to change at all: it's ok if emacsclient couldn't find itself on the $PATH that it receives.

@PureAbstract

This comment has been minimized.

Show comment Hide comment
@PureAbstract

PureAbstract Sep 20, 2013

Contributor

@tarsius That rather depends on what you mean by 'non-standard'...

I've seen other OS-X apps which put "helper" executables in directories below the main executable.
And of course, the logic in that defcustom already performs significant heroics to try and find an emacsclient in places other than the invocation-directory

Contributor

PureAbstract commented Sep 20, 2013

@tarsius That rather depends on what you mean by 'non-standard'...

I've seen other OS-X apps which put "helper" executables in directories below the main executable.
And of course, the logic in that defcustom already performs significant heroics to try and find an emacsclient in places other than the invocation-directory

@jasonm23

This comment has been minimized.

Show comment Hide comment
@jasonm23

jasonm23 Sep 20, 2013

@tarsius - BTW I was working with the emacs-mac-port build today, and I think there's something wrong with emacsclient, as I get successful client operations (using guard to alter my modeline on test red/green) but getting messages that it didn't find the Emacs server, (even though the modeline changes, and the op obviously took place.

I've just rebuilt from source so I can take a closer look at what's going on, more news later.

@tarsius - BTW I was working with the emacs-mac-port build today, and I think there's something wrong with emacsclient, as I get successful client operations (using guard to alter my modeline on test red/green) but getting messages that it didn't find the Emacs server, (even though the modeline changes, and the op obviously took place.

I've just rebuilt from source so I can take a closer look at what's going on, more news later.

mknoszlig pushed a commit to mknoszlig/magit that referenced this issue Oct 31, 2013

deal with strange location of emacsclient on OS X
On OS X applications are often installed in strange "executable
directories".  The Finder presents these directories as actual
applications to the user who might be blissfully unaware that
clicking on it actually executes a binary inside the directory.

So they have been happily clicking on a flashy image to start
Emacs and we come along requiring emacsclient being on $PATH.

But it gets worse.  The emacsclient executable might not even be
located in the same subdirectory of the application directory:

  /Applications/Emacs.app/Contents/MacOS/emacs
  /Applications/Emacs.app/Contents/MacOS/bin/emacsclient

So we have to look for the emacsclient here too:

  (expand-file-name "bin" invocation-directory)

Also see:

  magit#862 (comment)
@ksjogo

This comment has been minimized.

Show comment Hide comment
@ksjogo

ksjogo Jan 15, 2014

Hi,I am having this problem as well.
Emacs FSF trunk is used and installed.
I have set the magit emacsclient to /Applications/Emacs.app/Contents/MacOS/bin/emacsclient
But git is still opening another emacs instance.
Are there further settings to fix?

ksjogo commented Jan 15, 2014

Hi,I am having this problem as well.
Emacs FSF trunk is used and installed.
I have set the magit emacsclient to /Applications/Emacs.app/Contents/MacOS/bin/emacsclient
But git is still opening another emacs instance.
Are there further settings to fix?

@ksjogo

This comment has been minimized.

Show comment Hide comment
@ksjogo

ksjogo Jan 15, 2014

If I run git commit or emacsclient from my shell, it will open in the right emacs process.
Checking further it seems that git is for some reason falling back to alternate_editor, when called via magit.

ksjogo commented Jan 15, 2014

If I run git commit or emacsclient from my shell, it will open in the right emacs process.
Checking further it seems that git is for some reason falling back to alternate_editor, when called via magit.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Jan 15, 2014

Owner

How did you install emacs?

Owner

tarsius commented Jan 15, 2014

How did you install emacs?

@ksjogo

This comment has been minimized.

Show comment Hide comment
@ksjogo

ksjogo Jan 15, 2014

I copied the .app from nextstep to /Applications

ksjogo commented Jan 15, 2014

I copied the .app from nextstep to /Applications

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Jan 15, 2014

Owner

I was asking because if you had installed it with homebrew then the path to emacsclient would not have been correct.

Owner

tarsius commented Jan 15, 2014

I was asking because if you had installed it with homebrew then the path to emacsclient would not have been correct.

@ksjogo

This comment has been minimized.

Show comment Hide comment
@ksjogo

ksjogo Jan 15, 2014

I enabled tcp and now it works.

ksjogo commented Jan 15, 2014

I enabled tcp and now it works.

@ronaldevers

This comment has been minimized.

Show comment Hide comment
@ronaldevers

ronaldevers Jan 20, 2014

For the record, I'm using this in my init.el which I use on my Mac/homebrew (which is affected by this issue) and on linux:

(if (file-executable-p "/usr/local/bin/emacsclient")
    (setq magit-emacsclient-executable "/usr/local/bin/emacsclient"))

It's a bit crude and you may have to adapt to your situation, but it works for me.

@tarsius I enjoy magit and the improvements of the last year every day. It feels very slick, thanks a lot!

For the record, I'm using this in my init.el which I use on my Mac/homebrew (which is affected by this issue) and on linux:

(if (file-executable-p "/usr/local/bin/emacsclient")
    (setq magit-emacsclient-executable "/usr/local/bin/emacsclient"))

It's a bit crude and you may have to adapt to your situation, but it works for me.

@tarsius I enjoy magit and the improvements of the last year every day. It feels very slick, thanks a lot!

@john2x

This comment has been minimized.

Show comment Hide comment
@john2x

john2x Feb 27, 2014

I'm having this issue, but my magit-emacsclient-executable is already set to /usr/local/bin/emacsclient, which is in turn aliased to /usr/local/Cellar/emacs/24.3/bin/emacsclient. I've tried running emacs both in standalone mode, and --daemon and just connecting with emacsclient. Even if I'm running in an emacsclient, the commit window opens up a new instance of emacs (not using the server at all).

What's strange is before last night, I never had this issue. Only after a restart did it start happening (a restart due to installing OS X 10.9.2)

john2x commented Feb 27, 2014

I'm having this issue, but my magit-emacsclient-executable is already set to /usr/local/bin/emacsclient, which is in turn aliased to /usr/local/Cellar/emacs/24.3/bin/emacsclient. I've tried running emacs both in standalone mode, and --daemon and just connecting with emacsclient. Even if I'm running in an emacsclient, the commit window opens up a new instance of emacs (not using the server at all).

What's strange is before last night, I never had this issue. Only after a restart did it start happening (a restart due to installing OS X 10.9.2)

@bradneuman

This comment has been minimized.

Show comment Hide comment
@bradneuman

bradneuman Feb 27, 2014

This is not a real solution, but I found that magit was using /usr/bin/emacsclient, even though magit-emacsclient-executable was set to something else. As a workaround, I renamed /usr/bin/emacsclient to /usr/bin/emacsclient.bad and magit then started using the correct emacsclient (/usr/local/bin/emacsclient) instead, which is the one I had symlinked.

This is not a real solution, but I found that magit was using /usr/bin/emacsclient, even though magit-emacsclient-executable was set to something else. As a workaround, I renamed /usr/bin/emacsclient to /usr/bin/emacsclient.bad and magit then started using the correct emacsclient (/usr/local/bin/emacsclient) instead, which is the one I had symlinked.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Feb 27, 2014

Owner

@john2x what does "alias" mean here? A shell alias setup in something like ~/.bashrc or a symbolic link?

just connecting with emacsclient

As in "starting emacsclient from a shell"?

Even if I'm running in an emacsclient

What does that mean?

@bradneuman I have a hard time believing that. Please verify again that what you are saying is really true.

Owner

tarsius commented Feb 27, 2014

@john2x what does "alias" mean here? A shell alias setup in something like ~/.bashrc or a symbolic link?

just connecting with emacsclient

As in "starting emacsclient from a shell"?

Even if I'm running in an emacsclient

What does that mean?

@bradneuman I have a hard time believing that. Please verify again that what you are saying is really true.

@john2x

This comment has been minimized.

Show comment Hide comment
@john2x

john2x Feb 27, 2014

I "figured" out the issue. It seems to have been caused by my emacsclient not being able to find the default server socket. I added (setq server-socket-dir "/tmp/emacs") a few weeks ago to try and address the issue, and forgot about it (I never bothered to use emacsclient since).

It seems after the update+restart, emacsclient somehow learned to look at the default path for the socket (ignoring server-socket-dir to my confusion). Removing my custom server-socket-dir fixed my issue.

What I don't understand is that my emacsclient always had the issue of finding the socket before, but magit never complained until the update+restart.

john2x commented Feb 27, 2014

I "figured" out the issue. It seems to have been caused by my emacsclient not being able to find the default server socket. I added (setq server-socket-dir "/tmp/emacs") a few weeks ago to try and address the issue, and forgot about it (I never bothered to use emacsclient since).

It seems after the update+restart, emacsclient somehow learned to look at the default path for the socket (ignoring server-socket-dir to my confusion). Removing my custom server-socket-dir fixed my issue.

What I don't understand is that my emacsclient always had the issue of finding the socket before, but magit never complained until the update+restart.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Feb 27, 2014

Owner

The github traffic report tells me that over fifty users have visited this issue over the last two weeks. What is going on? Are you all OS X users? I haven't changed anything related to this recently, so it is unlikely that there is a new regression caused by changes to Magit itself. Have you updated OS X recently? What else have you done/changed that could affect this?

Owner

tarsius commented Feb 27, 2014

The github traffic report tells me that over fifty users have visited this issue over the last two weeks. What is going on? Are you all OS X users? I haven't changed anything related to this recently, so it is unlikely that there is a new regression caused by changes to Magit itself. Have you updated OS X recently? What else have you done/changed that could affect this?

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Feb 27, 2014

Owner

Also could those users who have already figured it out, please help the others.

Owner

tarsius commented Feb 27, 2014

Also could those users who have already figured it out, please help the others.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Feb 27, 2014

Owner

I added (setq server-socket-dir "/tmp/emacs") a few weeks ago [...] and forgot about it

I will look into how I can work around this kind of misconfiguration too.

Owner

tarsius commented Feb 27, 2014

I added (setq server-socket-dir "/tmp/emacs") a few weeks ago [...] and forgot about it

I will look into how I can work around this kind of misconfiguration too.

@john2x

This comment has been minimized.

Show comment Hide comment
@john2x

john2x Feb 28, 2014

Have you updated OS X recently?

Yes. Updated to 10.9.2 and restarted. That's when the trouble started.

I wish I knew what was wrong with Homebrew's emacsclient, but I really don't have any idea. :( All I know is that before updating, my emacsclient was broken, but magit had no issues. After the update, emacsclient was fixed, but my settings trying to fix emacsclient broke magit.

john2x commented Feb 28, 2014

Have you updated OS X recently?

Yes. Updated to 10.9.2 and restarted. That's when the trouble started.

I wish I knew what was wrong with Homebrew's emacsclient, but I really don't have any idea. :( All I know is that before updating, my emacsclient was broken, but magit had no issues. After the update, emacsclient was fixed, but my settings trying to fix emacsclient broke magit.

@fophillips

This comment has been minimized.

Show comment Hide comment
@fophillips

fophillips Mar 14, 2014

I found that magit was using /usr/bin/emacsclient, even though magit-emacsclient-executable was set to something else.

I can confirm this happening for me too, on OS X 10.9.2 and Emacs built from Homebrew.

I found that magit was using /usr/bin/emacsclient, even though magit-emacsclient-executable was set to something else.

I can confirm this happening for me too, on OS X 10.9.2 and Emacs built from Homebrew.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Mar 14, 2014

Owner

How did you determine that this is the case? Try to commit, press $ to open the log buffer, go to the last section, press TAB to expand it. Do you now see something like:

Waiting for Emacs...
error: There was a problem with the editor '/usr/bin/emacsclient --socket-name=/tmp/emacs1000/server'.
Please supply the message using either -m or -F option.

I.e. does it really say /usr/bin/emacsclient and (eval-expression magit-emacsclient-executable) really sais something else?

Owner

tarsius commented Mar 14, 2014

How did you determine that this is the case? Try to commit, press $ to open the log buffer, go to the last section, press TAB to expand it. Do you now see something like:

Waiting for Emacs...
error: There was a problem with the editor '/usr/bin/emacsclient --socket-name=/tmp/emacs1000/server'.
Please supply the message using either -m or -F option.

I.e. does it really say /usr/bin/emacsclient and (eval-expression magit-emacsclient-executable) really sais something else?

@fophillips

This comment has been minimized.

Show comment Hide comment
@fophillips

fophillips Mar 14, 2014

Yes, the message in *magit-process* says /usr/bin/emacsclient. In my .emacs I have (setq magit-emacsclient-executable "/usr/local/bin/emacsclient"), C-h v magit-emacsclient-executable says /usr/local/bin/emacsclient, yet (eval-expression magit-emacsclient-executable) says "/usr/local/bin/emacsclient""/usr/bin/emacsclient"

Yes, the message in *magit-process* says /usr/bin/emacsclient. In my .emacs I have (setq magit-emacsclient-executable "/usr/local/bin/emacsclient"), C-h v magit-emacsclient-executable says /usr/local/bin/emacsclient, yet (eval-expression magit-emacsclient-executable) says "/usr/local/bin/emacsclient""/usr/bin/emacsclient"

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Mar 14, 2014

Owner

Is this supposed to read:

yet (eval-expression magit-emacsclient-executable) says "/usr/bin/emacsclient"

or

yet (eval-expression magit-emacsclient-executable) says "/usr/local/bin/emacsclient"

Please correct that, this issue is confusing enough without this copy-paste error.

Owner

tarsius commented Mar 14, 2014

Is this supposed to read:

yet (eval-expression magit-emacsclient-executable) says "/usr/bin/emacsclient"

or

yet (eval-expression magit-emacsclient-executable) says "/usr/local/bin/emacsclient"

Please correct that, this issue is confusing enough without this copy-paste error.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Mar 14, 2014

Owner

The only place in Magit where the value of the variable magit-emacsclient-executable is set is this:

(defcustom magit-emacsclient-executable
  (do stuff here)
  "The Emacsclient executable. ..."
  ...)

Could you please grep all of your elisp files for something else that sets this variable. Look especially for things that set the local value of this variable (which shouldn't be done in the first place).

Owner

tarsius commented Mar 14, 2014

The only place in Magit where the value of the variable magit-emacsclient-executable is set is this:

(defcustom magit-emacsclient-executable
  (do stuff here)
  "The Emacsclient executable. ..."
  ...)

Could you please grep all of your elisp files for something else that sets this variable. Look especially for things that set the local value of this variable (which shouldn't be done in the first place).

@fophillips

This comment has been minimized.

Show comment Hide comment
@fophillips

fophillips Mar 14, 2014

It's not a copy-paste error, it actually says that.

It's not a copy-paste error, it actually says that.

@npostavs

This comment has been minimized.

Show comment Hide comment
@npostavs

npostavs Mar 14, 2014

Member

Doing M-: (eval-expression magit-emacsclient-executable) RET gave me
"/usr/local/bin/emacsclient""/usr/local/bin/emacsclient"

It sort of makes sense to get 2 results because eval-expression is bound to M-:. I can't quite see how it's possible to get 2 different results though.

Member

npostavs commented Mar 14, 2014

Doing M-: (eval-expression magit-emacsclient-executable) RET gave me
"/usr/local/bin/emacsclient""/usr/local/bin/emacsclient"

It sort of makes sense to get 2 results because eval-expression is bound to M-:. I can't quite see how it's possible to get 2 different results though.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Mar 14, 2014

Owner

It confused my but two strings being printed to *Messages* actually makes sense. I would have expected these two strings to appear on separate lines though. My instructions were a bit silly - I meant to say "evaluate the expression magit-emacsclient-executable". But the way I phrased it you ended up using eval-last-sexp and eval-expression both of which print the value of some expression to *Messages*. In the case of eval-last-sexp that expression is actually (eval-expression magit-emacsclient-executable) and not magit-emacsclient-excutable. It looks like the value returned by eval-expression is undefined (i.e. something is returned and that something doesn't hold any particular meaning. It appears to be some recent value).

So do this:

  1. M-: magit-emacsclient-executable RET
  2. Put the text magit-emacsclient-executable into some buffer, move point after that text, and press C-x C-e.

Both will print "/usr/local/bin/emacsclient". (Right?). Now that we have established what the value of the variable is, let's move on to the actual issue.

Owner

tarsius commented Mar 14, 2014

It confused my but two strings being printed to *Messages* actually makes sense. I would have expected these two strings to appear on separate lines though. My instructions were a bit silly - I meant to say "evaluate the expression magit-emacsclient-executable". But the way I phrased it you ended up using eval-last-sexp and eval-expression both of which print the value of some expression to *Messages*. In the case of eval-last-sexp that expression is actually (eval-expression magit-emacsclient-executable) and not magit-emacsclient-excutable. It looks like the value returned by eval-expression is undefined (i.e. something is returned and that something doesn't hold any particular meaning. It appears to be some recent value).

So do this:

  1. M-: magit-emacsclient-executable RET
  2. Put the text magit-emacsclient-executable into some buffer, move point after that text, and press C-x C-e.

Both will print "/usr/local/bin/emacsclient". (Right?). Now that we have established what the value of the variable is, let's move on to the actual issue.

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Mar 14, 2014

Owner

Apply this patch:

diff --git a/magit.el b/magit.el
index 4c8d51f..c375064 100644
--- a/magit.el
+++ b/magit.el
@@ -6239,8 +6239,10 @@ depending on the value of option `magit-commit-squash-commit'.
 (defun magit-commit-internal (subcmd args)
   (setq git-commit-previous-winconf (current-window-configuration))
   (if (magit-use-emacsclient-p)
-      (magit-with-emacsclient magit-server-window-for-commit
-        (magit-run-git-async subcmd args))
+      (progn (message "--- on emacsclient path")
+             (magit-with-emacsclient magit-server-window-for-commit
+                                     (magit-run-git-async subcmd args)))
+    (message "--- on crap path")
     (let ((topdir (magit-get-top-dir))
           (editmsg (magit-git-dir (if (equal subcmd "tag")
                                       "TAG_EDITMSG"

Which path are you on?

Owner

tarsius commented Mar 14, 2014

Apply this patch:

diff --git a/magit.el b/magit.el
index 4c8d51f..c375064 100644
--- a/magit.el
+++ b/magit.el
@@ -6239,8 +6239,10 @@ depending on the value of option `magit-commit-squash-commit'.
 (defun magit-commit-internal (subcmd args)
   (setq git-commit-previous-winconf (current-window-configuration))
   (if (magit-use-emacsclient-p)
-      (magit-with-emacsclient magit-server-window-for-commit
-        (magit-run-git-async subcmd args))
+      (progn (message "--- on emacsclient path")
+             (magit-with-emacsclient magit-server-window-for-commit
+                                     (magit-run-git-async subcmd args)))
+    (message "--- on crap path")
     (let ((topdir (magit-get-top-dir))
           (editmsg (magit-git-dir (if (equal subcmd "tag")
                                       "TAG_EDITMSG"

Which path are you on?

@fophillips

This comment has been minimized.

Show comment Hide comment
@fophillips

fophillips Mar 21, 2014

Ok, it turns out it was me doing something dodgy and is sorted now! Is it expected behaviour to open the commit buffer in a new frame?

Ok, it turns out it was me doing something dodgy and is sorted now! Is it expected behaviour to open the commit buffer in a new frame?

@tarsius

This comment has been minimized.

Show comment Hide comment
@tarsius

tarsius Mar 21, 2014

Owner

The option that controls this is magit-server-window-for-commit, it overrides server-window. The technique used to do so is a bit fragile and might at times fail. On the next branch I have improved and simplified that, but it will be a while until that gets merged into master.

Check these two variables. If you are not using the emacsclient for other things too, then you might want to set both variables to pop-to-buffer.

Owner

tarsius commented Mar 21, 2014

The option that controls this is magit-server-window-for-commit, it overrides server-window. The technique used to do so is a bit fragile and might at times fail. On the next branch I have improved and simplified that, but it will be a while until that gets merged into master.

Check these two variables. If you are not using the emacsclient for other things too, then you might want to set both variables to pop-to-buffer.

@fophillips

This comment has been minimized.

Show comment Hide comment
@fophillips

fophillips Mar 21, 2014

Great, thanks.

Great, thanks.

@bradneuman

This comment has been minimized.

Show comment Hide comment
@bradneuman

bradneuman Mar 21, 2014

Could you share what it was that you were doing that was dodgy? It sounds
like I have the same situtation

On Fri, Mar 21, 2014 at 8:27 AM, fophillips notifications@github.comwrote:

Great, thanks.

Reply to this email directly or view it on GitHubhttps://github.com/magit/magit/issues/862#issuecomment-38287093
.

Could you share what it was that you were doing that was dodgy? It sounds
like I have the same situtation

On Fri, Mar 21, 2014 at 8:27 AM, fophillips notifications@github.comwrote:

Great, thanks.

Reply to this email directly or view it on GitHubhttps://github.com/magit/magit/issues/862#issuecomment-38287093
.

@fophillips

This comment has been minimized.

Show comment Hide comment
@fophillips

fophillips Mar 21, 2014

I'd managed to mess up my magit repo without realising, so I wasn't actually using the version I thought I was. Make sure you're fully up to date with master.

I'd managed to mess up my magit repo without realising, so I wasn't actually using the version I thought I was. Make sure you're fully up to date with master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment