When I typed C-y to call yank, I got this.

apply: Symbol's value as variable is void: n

Debugger entered--Lisp error: (void-variable n)
ad-Advice-current-kill( ... [interprogram-paste-function interprogram-cut-function kill-ring kill-ring-yank-pointer yank-pop-change-selection 0 nil mapc kill-new error "Kill ring is empty" mod] 6 2016971] 0)
apply(ad-Advice-current-kill ... [interprogram-paste-function interprogram-cut-function kill-ring kill-ring-yank-pointer yank-pop-change-selection 0 nil mapc kill-new error "Kill ring is empty" mod] 6 2016971] 0)
call-interactively(yank nil nil)

The '...' in the traceback is messy code.

I have found it's this sentence that caused this error.

(require 'multiple-cursors)

The contents after querying function current-kill.

current-kill is a compiled Lisp function in `simple.el'.

(current-kill ARG1 &optional ARG2)

:around advice: `ad-Advice-current-kill'

And the contents after pressing ad-Advice-current-kill.

ad-Advice-current-kill is a compiled Lisp function.

(ad-Advice-current-kill AD--ADDOIT-FUNCTION ARG1 &optional ARG2)

Before-advice `interprogram-paste-for-all-cursors'.

It's really inconvenient that yank can't work. Hoping to solve it quickly, I post the source code for interprogram-paste-for-all-cursors

(defadvice current-kill (before interprogram-paste-for-all-cursors activate)
  (let ((interprogram-paste (and (= n 0)
                                 (funcall interprogram-paste-function))))
    (when interprogram-paste
      ;; Add interprogram-paste to normal kill ring, just
      ;; like current-kill usually does for itself.
      ;; We have to do the work for it tho, since the funcall only returns
      ;; something once. It is not a pure function.
      (let ((interprogram-cut-function nil))
        (if (listp interprogram-paste)
            (mapc 'kill-new (nreverse interprogram-paste))
          (kill-new interprogram-paste))
        ;; And then add interprogram-paste to the kill-rings
        ;; of all the other cursors too.
         (let ((kill-ring (overlay-get cursor 'kill-ring))
               (kill-ring-yank-pointer (overlay-get cursor 'kill-ring-yank-pointer)))
           (if (listp interprogram-paste)
               (mapc 'kill-new (nreverse interprogram-paste))
             (kill-new interprogram-paste))
           (overlay-put cursor 'kill-ring kill-ring)
           (overlay-put cursor 'kill-ring-yank-pointer kill-ring-yank-pointer)))))))
  • 1
    This is extremely weird, but the first way to understand the error would be to M-x toggle-debug-on-error to get the backtrace of the error.
    – wvxvw
    Nov 28, 2016 at 15:02
  • Do you see the same thing when you start Emacs using emacs -Q (no init file)? If yes then M-x report-emacs-bug, providing a step-by-step recipe. If no, recursively bisect your init file to find the culprit.
    – Drew
    Nov 28, 2016 at 15:24
  • @Drew With no init file to restart emacs, yank works normally.
    – moyotar
    Nov 28, 2016 at 15:28
  • 1
    Then bisect your init file to find out what causes the problem. You can use comment-region to comment out 1/2, then 3/4, 7/8, 15/16,... until you isolate the problem. It's very quick to do. With C-u, comment-region uncomments the region.
    – Drew
    Nov 28, 2016 at 15:37
  • 1
    Oh, good to hear it worked. Will it influence anything else? - rather unlikely, but, I believe the maintainer would give you a better answer.
    – wvxvw
    Nov 30, 2016 at 15:40

1 Answer 1


The answer I believe is that the argument list for current-kill as defined in your session is (ARG1 &optional ARG2), whereas the argument list in at least the current release version of emacs is (N &optional DO-NOT-MOVE). The important difference is the replacement of N with ARG1 in your version.

If you look at the very beginning of the defadvice that you posted, it expects N to be defined. In the release version of emacs, N is bound when current-kill is called, but in your case the value that would be bound to N is bound to ARG1 instead.

Looking through the git history for emacs quickly, I couldn't find a point at which current-kill had the same argument list as the definition you provided, so my guess is that in one of your packages (or some code you are loading) current-kill is being redefined with a different argument list. That's just a guess though.

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.