Adam Porter <adam@alphapapa.net> writes:
This is a very strange backtrace.
When I run that `alist-get' call manually, there is no error. And
`alist-get' does not call `car'.
May you try to re-generate the backtrace again?
It is indeed strange. I generated the backtrace several times over
several sessions before reporting. I also can reproduce it in a clean
Emacs configuration like so:
You re-define `alist-get' in one of the callers in a way that cannot
handle normal alists like (key . value), not (key . list-value).
(cl-defun burly-follow-url-org-mode (&key buffer query)
"In BUFFER, jump to heading and position from QUERY, and return a buffer.
If QUERY specifies that the buffer should be indirect, a new,
indirect buffer is returned. Otherwise BUFFER is returned."
;; `pcase's map support uses `alist-get', which does not work with string
keys
;; unless its TESTFN arg is bound to, e.g. `equal', but `map-elt' has
deprecated
;; its TESTFN arg, and there's no way to pass it or bind it when using
`pcase'
;; anyway. So we rebind `alist-get' to a function that uses `assoc-string'.
(with-current-buffer buffer
(cl-letf (((symbol-function 'alist-get)
(lambda (key alist &optional _default _remove _testfn)
;; Only the first value in the list of values is returned, so
multiple
;; values are not supported. I don't expect this to be a
problem...
(cadr (assoc-string key alist)))))
Handled.
Not an Org bug.