Cannot commit with new commit workflow: wrong-type-argument stringp, nil

[zachallaun]

Hi there,

I've just upgraded magit and am running into an error when trying to commit: wrong-type-argument stringp, nil. Everything was previously working with the old-style commit workflow (c immediately dropping you into a log buffer, etc). I've confirmed that committing also fails in a brand-new git repo, but I'm not sure where to go from here.

The exact operations that lead to the error:

1. M-x magit-status
2. s to stage a file
3. c to begin commit
4. c to commit without any options -- this causes the error

Backtrace:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  file-name-directory(nil)
  magit-commit(nil)
  call-interactively(magit-commit)
  magit-key-mode-command(magit-commit)
  (lambda nil (interactive) (magit-key-mode-command (quote magit-commit)))()
  call-interactively((lambda nil (interactive) (magit-key-mode-command (quote magit-commit))) nil nil)
  command-execute((lambda nil (interactive) (magit-key-mode-command (quote magit-commit))))

[tarsius]

Let me guess you are on OS X? Any ways just pushed a quick fix.

[tarsius]

But then you might run into #770.

[zachallaun]

Thanks for the quick fix! Not sure if there's more to be done, but if not, feel free to close.

[vermiculus]

Still doesn't work for me on Windows 8. (At least, not with the most current MELPA build. I'll confirm that it doesn't work early tomorrow/in a few hours.)

I narrowed the issue down a bit:

(magit-with-git-editor-setup magit-server-window-for-commit
      (apply 'magit-run-git-async "commit" magit-custom-options))

Executing this inside my magit-status buffer (with toggle-debug-on-error) yeilds

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  file-name-directory(nil)
  (let* ((process-environment process-environment) (magit-process-popup-time -1) (window43400 magit-server-window-for-commit) (bindir43401 (file-name-directory (cdr (assq (quote args) (process-attributes (emacs-pid)))))) (client43402 (and bindir43401 (expand-file-name "emacsclient" bindir43401)))) (unless (and client43402 (file-executable-p client43402)) (setq client43402 (executable-find "emacsclient"))) (unless (magit-server-running-p) (server-start)) (cond ((not client43402) (message (concat "Cannot find emacsclient (check $PATH); " "using default $GIT_EDITOR"))) ((string= server-name "server") (setenv "GIT_EDITOR" client43402)) ((eq system-type (quote windows-nt)) (message (concat "Cannot set server name on Windows; " "using default $GIT_EDITOR"))) (t (setenv "GIT_EDITOR" (format "%s -s %s" client43402 server-name)))) (unless (equal window43400 server-window) (run-at-time "0.2 sec" nil (apply-partially (lambda (value) (setq server-window value)) server-window)) (setq-default server-window window43400)) (apply (quote magit-run-git-async) "commit" magit-custom-options))
  (magit-with-git-editor-setup magit-server-window-for-commit (apply (quote magit-run-git-async) "commit" magit-custom-options))
  eval((magit-with-git-editor-setup magit-server-window-for-commit (apply (quote magit-run-git-async) "commit" magit-custom-options)) nil)
  eval-expression((magit-with-git-editor-setup magit-server-window-for-commit (apply (quote magit-run-git-async) "commit" magit-custom-options)) nil)
  call-interactively(eval-expression nil nil)
  recursive-edit()
  debug(error (wrong-type-argument stringp nil))
  file-name-directory(nil)
  magit-commit(nil)
  call-interactively(magit-commit)
  magit-key-mode-command(magit-commit)
  (lambda nil (interactive) (magit-key-mode-command (quote magit-commit)))()
  call-interactively((lambda nil (interactive) (magit-key-mode-command (quote magit-commit))) nil nil)

Hopefully that deluge of information will help figure out what's going on here.

[tarsius]

The melpa build probably just hasn't happened yet. There is just one file-name-directory involved and that is now wrapped with ignore-errors.

[vermiculus]

Still getting an error on stage->commit:

$ git --no-pager commit
warning: LF will be replaced by CRLF in rhotex.tex.
The file will have its original line endings in your working directory.
c:/bin/emacs-24.2/bin/emacsclient.exe: No socket or alternate editor.  Please use:

    --server-file      (or environment variable EMACS_SERVER_FILE)
    --alternate-editor (or environment variable ALTERNATE_EDITOR)
error: There was a problem with the editor 'c:/bin/emacs-24.2/bin/emacsclient.exe'.
Please supply the message using either -m or -F option.
git exited abnormally with code 1.

but perhaps this is now a different issue?

[tarsius]

Yes that's a different issue (windows particularities vs. osx particularities) but we might as well discuss it here.

c:/bin/emacs-24.2/bin/emacsclient.exe: No socket or alternate editor.

This could either mean that magit failed to detect that it needs to start the server or that the server file is created in an unexpected location.

Could you please start Emacs as usual (not -Q) and try to connect from a terminal using emacsclient somefile. Does that give you the same error?

Then manually start the server with (server-start) and try again.

[vermiculus]

Nope, the error does not persist (at least on my work computer).

I will double-check that I'm doing anything 'fancy' on my desktop at home; I didn't know runemacs.exe started the server automatically and I may have tried some awful cmd hacking to make it smarter.

---

by the way, the new commit buffer looks really nice 😃

[tarsius]

What is runemacs.exe? I would have expected the Emacs binary to be named emacs.exe.

Please check whether #797 fixes this.

[vermiculus]

runemacs.exe is a wrapper around emacs.exe provided in the GNU package. Looking at the binary from emacs itself, it seems as if it handles special stuff specific to Windows' window system. Invoking emacs.exe directly spawns a command prompt window in addition to the main emacs window that is tied to the same process, so presumably runemacs.exe's only purpose is to circumvent this. (runemacs.exe is also less than 100K.)

As for trying out #797 --- should I pull f6b2aa9 or 09bbd97?

---

The most recent MELPA build (after restarting emacs entirely) gives me an error upon magit-status:

Symbol's value as variable is void: magit-log-edit-confirm-cancellation

with the following trace:

Debugger entered--Lisp error: (void-variable magit-log-edit-confirm-cancellation)
  eval(magit-log-edit-confirm-cancellation)
  custom-initialize-reset(magithub-message-confirm-cancellation magit-log-edit-confirm-cancellation)
  custom-declare-variable(magithub-message-confirm-cancellation magit-log-edit-confirm-cancellation "If non-nil, confirm when cancelling the editing of a `magithub-message-mode' buffer." :group magithub :type boolean)
  eval-buffer(#<buffer  *load*> nil "c:/Users/sallred/AppData/Roaming/.emacs.d/elpa/magithub 20130718.2320/magithub.el" nil t)  ; Reading at buffer position 1384
  load-with-code-conversion("c:/Users/sallred/AppData/Roaming/.emacs.d/elpa/magithub 20130718.2320/magithub.el" "c:/Users/sallred/AppData/Roaming/.emacs.d/elpa/magithub-20130718.2320/magithub.el" nil t)
  require(magithub)
  (if (featurep (quote magithub)) nil (require (quote magithub)))
  (unless (featurep (quote magithub)) (require (quote magithub)))
  (lambda nil (unless (featurep (quote magithub)) (require (quote magithub))))()
  funcall((lambda nil (unless (featurep (quote magithub)) (require (quote magithub)))))
  (if (not (equal file (quote "c:/Users/sallred/AppData/Roaming/.emacs.d/elpa/magit-20130822.1825/magit.el"))) nil (remove-hook (quote after-load-functions) (quote eval-after-load-helper)) (funcall (quote (lambda nil (unless (featurep (quote magithub)) (require (quote magithub)))))))
  eval-after-load-helper("c:/Users/sallred/AppData/Roaming/.emacs.d/elpa/magit-20130822.1825/magit.el")
  run-hook-with-args(eval-after-load-helper "c:/Users/sallred/AppData/Roaming/.emacs.d/elpa/magit-20130822.1825/magit.el")
  do-after-load-evaluation("c:/Users/sallred/AppData/Roaming/.emacs.d/elpa/magit-20130822.1825/magit.el")
  load-with-code-conversion("c:/Users/sallred/AppData/Roaming/.emacs.d/elpa/magit-20130822.1825/magit.el" "c:/Users/sallred/AppData/Roaming/.emacs.d/elpa/magit-20130822.1825/magit.el" nil t)

[PureAbstract]

As for trying out #797 --- should I pull f6b2aa9 or 09bbd97?

09bbd97 - it has the fixed scope for version

[tarsius]

Also see nex3/magithub#12 regarding magit-log-edit-confirm-cancellation.

[tarsius]

Closing because the initial OS X issue is fixed, the middle Windows issue is fixed, and the last issue does not belong here. I should have insisted on separately reported issues. :-/

The code where the first two issues surfaced has been removed. On OS X I am sure the initial cause has also been fixed. On Windows I don't know that the initial cause was, but I suspect it was the same. If you still have this problem please open a new issue.

[vermiculus]

but perhaps this is now a different issue?

Agreed.

I'll try a clean install and open a new issue if it persists.

[vermiculus]

Turns out that server.el wasn't looking in the right place for the server file. This probably has nothing to do with magit at this point, but to note that it isn't a magit problem:

(setenv "EMACS_SERVER_FILE" (expand-file-name "server/server" user-emacs-directory))

in .emacs fixes the issue (at least as far as magit is concerned). I am using the as-yet-most-recent MELPA build, so no fancy stuff going on here.

[tarsius]

That's very useful information but could you please open a new issue.

[Apteryks]

For the record, I had this error as well, but not for the same reason: it was caused by the emacs-diff-hl package that I use. It has a magit hook that misbehaved before this commit: dgutov/diff-hl@f8ce39d#diff-7f5249a920cb714b91e751d32b9dc9ef (available as of version 1.8.5).