Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> A git bisect revealed that the change was introduced in 2015 with the >> following commit: >> >> ,---- >> | commit 50ba0a5ed609f3600f2590f3ba22b8ab3ff3331c >> | Author: Nicolas Goaziou <m...@nicolasgoaziou.fr> >> | Date: Sun Jun 7 00:38:58 2015 +0200 >> | >> | Fix 1a7364177046b8a57ade0aeb9f52bacfc0b8b088 >> | >> | * lisp/org.el (org-icompleting-read): Let `completing-read' or >> | equivalent sort out type of completion. >> | (org-olpath-completing-read): Revert partially >> | 1a7364177046b8a57ade0aeb9f52bacfc0b8b088. >> `---- >> >> It looks like this commit removed some functionality from the now >> obsolete org-icompleting-read that made sure that the items in the >> completion list passed to the completing read function were strings. > > Actually, this is a bug in "ido.el", since `ido-completing-read' is not > a drop-in replacement for `completing-read'. The latter accepts lists > of strings, but also alist, obarrays and hash tables. The former accepts > only list of strings. > > I suggest to report the bug to "ido.el" maintainers since they probably > want to preserve compatibility between the completion functions.
OK. Thanks. I see that a bug report has been on the emacs list since 2013: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15430 For the time being, it's easy enough to write a custom wrapper around ido-completing-read, so I think I'll do that. It's worth nothing that the author of patch that originally added the completing-read-function variable did not anticipate that ido-completing-read would be a simple drop-in for completing-read: http://thread.gmane.org/gmane.emacs.devel/134000 For a long time (since at least 2009), org-mode had built-in support for ido-mode completion when refiling. So this does seem to be a deprecation of longstanding org-mode functionality. I'll see if we can add something to the docstrings to alert of the need to write a wrapper around ido-completing-read. Matt
