I have the following in my org-mode buffer:

#+name: my-element-name

and then I made a link to that:

and here is a link to [[my-element-name]].

According to the org-mode manual on internal links, that ought to work, but when I try to following the link with C-c C-o, I get an error: Wrong type argument: stringp, nil.

I'm using org 9.4 from ELPA; I've used edebug on some of the functions and it seems that something isn't working deep inside org-link-search but I couldn't figure out where. I see some regexp matching in that function...this seems like something that ought to work.

Using NAME instead of "name" didn't make a difference.

Is this expected to work? It seems like it.

(More generally, what's the difference between "dedicated targets" -- the ones <<like-this>> -- versus "named elements" with #+NAME: some-name-here?)

1 Answer 1


A name keyword is an "affiliated" keyword: it is affiliated to the following element, so it cannot exist on its own.


#+name: my-table
| a | b |

#+name: my-code-block
#+begin_src emacs-lisp
(message "foo")


If you do M-x org-lint in your buffer, you'll see something like this:

     6 low   Orphaned affiliated keyword: "NAME"
    17 high  Unknown fuzzy location "my-element-name"
  • Thanks! However, when I run org-lint, I get: 17 files scanned, 16 files contains IDs, and 908 IDs found. Not enough arguments for format string.
    – Dan Drake
    Commented Oct 1, 2020 at 10:13
  • No idea why you get that - can you M-x toggle-debug-on-error RET and try the org-lint again? If you get a decent backtrace, maybe you can open another question on that or send a bug report with M-x org-submit-bug-report RET, including the backtrace in the bug report.
    – NickD
    Commented Oct 1, 2020 at 13:25

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.