When I try to commit using magit I get the following error;

 1 git … commit --
Waiting for Emacs...
*ERROR*: Wrong type argument: stringp, nil
error: There was a problem with the editor '/opt/emacs/bin/emacsclient --socket-name=/tmp/emacs1000/server'.
Please supply the message using either -m or -F option.

Here are the versions of software I'm using

Magit 20160814.1615, Git 2.9.0, Emacs, gnu/linux (Debian wheezy 7)

I run emacs as a server.

If I type the following into a file within my git project and eval the buffer I get the following;

  (let ((magit-git-debug t)
         (cons "GIT_EDITOR=printf '[%s]\n' \"$EDITOR\"" process-environment)))
    (magit-git-insert "commit")))[/opt/emacs/bin/emacsclient --socket-name=/tmp/emacs1000/server]

On the command line if I do the following

$ export GIT_TRACE=1 
$ export GIT_EDITOR='printf "[%s]\n" "$EDITOR"'                                             
$ git commit 
10:48:43.558746 git.c:350               trace: built-in: git 'commit'
10:48:43.561811 run-command.c:336       trace: run_command: '.git/hooks/pre-commit'
10:48:43.563366 run-command.c:336       trace: run_command: 'status' '--porcelain'
10:48:43.563595 exec_cmd.c:120          trace: exec: 'git' 'status' '--porcelain'
10:48:43.564766 git.c:350               trace: built-in: git 'status' '--porcelain'
10:48:43.574334 run-command.c:336       trace: run_command: 'printf "[%s]\n" "$EDITOR"' '/home/map7/code/testproject/.git/COMM
10:48:43.574637 run-command.c:195       trace: exec: '/bin/sh' '-c' 'printf "[%s]\n" "$EDITOR" "$@"' 'printf "[%s]\n" "
$EDITOR"' '/home/map7/code/testproject/.git/COMMIT_EDITMSG'                                                                  
[emacs -nw -q]
Aborting commit due to empty commit message.
10:48:43.581313 git.c:350               trace: built-in: git 'config' '--get' 'oh-my-zsh.hide-dirty' 


I just restarted emacs and now I can commit again, but I don't know for how long.

I can re-enact a similar problem if I do the following

  1. Stage my changes in magit using 's' on a file
  2. Go to commit hitting 'c c'
  3. Cancel the commit 'C-c C-k'

Now I get the same error as I was getting before, when trying to commit.

UPDATE: error in Backtrace

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  server-goto-toplevel(#<process server <24>>)
  server-process-filter(#<process server <24>> "-dir /home/map7/code/angularjs_nested_routes/ -current-frame -tty /dev/pts/31 dumb -file /home/map7/code/angularjs_nested_routes/.git/COMMIT_EDITMSG \n")


I've been busy testing my configuration by remarking parts out as suggested. I recently had the same error, but manage to fix the error by killing off some of my buffers. I didn't take note of which buffers, but I will next time. This may suggest that it's a certain state instead of configuration?

  • 25.0.50 is an old unstable version of Emacs, have you tried with 25.1-rc1 (or wait a day or so for rc2)? Also, the command line test should be export GIT_EDITOR='printf "[%s]\n" "$EDITOR"', note the quotes have to go around the printf and its arguments.
    – npostavs
    Aug 17, 2016 at 0:42
  • Try evaluating (setq debug-on-signal t) before committing to get a backtrace with the error.
    – npostavs
    Aug 17, 2016 at 1:28
  • I ran that setq in the scratch and when the error happens I don't get anymore information.
    – map7
    Aug 18, 2016 at 1:49
  • you did use debug-on-SIGNAL, not debug-on-ERROR? (the latter doesn't work with emacsclient). With debug-on-signal you should get a backtrace buffer popping up in Emacs (that's what I got when I inserted an error by hand).
    – npostavs
    Aug 18, 2016 at 2:13
  • debug-on-signal didn't work so I just tried debug-on-error and this worked. I'm running exwm (Emacs X Windows Manager), so I don't think I'm running a emacsclient, although exwm does start an emacs daemon.
    – map7
    Aug 18, 2016 at 3:13

3 Answers 3


I encountered this too, and traced the problem a fraction further, within the isearch-done function. The source of the stringp error is this line:

(with-current-buffer isearch--current-buffer

with-current-buffer expects that its first parameter is a string, but at this point isearch--current-buffer is nil. I'm 80% sure that this is because server-goto-toplevel calls isearch-cancel just in case isearch is currently active, presumably because if it was it would interfere with the server or client somehow - but if it's not active then this error happens.

The good news is that it seems that this bug has already been fixed, and indeed manually patching isearch.el with this fix seems to do the trick!

  • 1
    Hmm, server-goto-toplevel only calls isearch-cancel if isearch-mode is non-nil, I wonder how isearch--current-buffer and isearch-mode get desynchronized. Unlucky C-g? Or do you recursively edit while isearching (the code around that looks tricky, perhaps it doesn't recover from it correctly)?
    – npostavs
    Nov 7, 2016 at 13:31
  • Good question. I'm not sure but I think I probably do occasionally recursively edit while isearching, although maybe sometimes by accident ... Nov 7, 2016 at 14:40

Based on @Adam Spiers' answer, I ran the following

(dolist (buffer (buffer-list))
  (with-current-buffer buffer
    (when (bound-and-true-p isearch-mode)
      (message "Try isearch-ing in %s" buffer))))

which identified a buffer. I then went to that buffer, started isearch, exited isearch normally, and then things went back to normal. The issue for me was that isearch-mode was non-nil (so it thought it had to call isearch-cancel), but isearch--current-buffer was nil (so cancelling threw an error).

  • The code snippet here provides a solution that allows fixing the issue quickly and without having to restart Emacs or upgrade, or do anything time-consuming. I ran the snippet, got the name of the buffer that was problematic, started and cancelled isearch there, and the problem was gone.
    – Louis
    May 1, 2018 at 14:42

While it can of course not be completely ruled out that Magit and/or with-editor in some way at least contribute to this error, it most likely is causes by a local configuration issue.

This question can therefore not be answered by someone who does not have access to the machine on which the error occurs. We can only provide tips about how to best locate the cause.

The cause of the error has to be isolated by performing a binary-"commenting-out"-search on the user's init file and/or by making educated guesses about what might be the cause and looking specifically in those places. Since the issue apparently cannot be reproduced consistently, the latter might be the only option.

Since isearch-cancel appeared in a backtrace, looking for strange things involving isearch would be a good start.

Also check the values of the hooks server-visit-hook, server-switch-hook, and server-done-hook. Is there anything on those hooks that shouldn't be?

  • 1
    We have checked hooks with C-h v and there is nothing there which is obvious. I've got one machine in error state and another working. We have been able to fix the problem now by closing buffers instead of a restart of emacs.
    – map7
    Oct 27, 2016 at 2:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.