Looking at this again I realize that the reason for this behavior is that we want completion of possibly several tags. This is what the "org-tags-completion-function" does when supplied as the second argument of "completing-read". As "ido-completing-read" and "org-iswitchb-completing-read" doesn't support this, they are not used.

I don't know if there would be a way of getting both ido and multiple input. As it is now though, it's pretty meaningless to have that call to org-icompleting-read there as it never gets activated. It could as well be:

(completing-read "Tags: "
        nil nil current 'org-tags-history)))))

Anders Johansson

2013-11-01 02:33, Eric Abrahamsen skrev:
Anders Johansson <mejlaande...@gmail.com> writes:

I want to use ido everywhere and wanted to know why this doesn't seem
to work for setting org-mode tags (it never has for me).

Using edebug to step through the call to org-icompleting-read which
org-set-tags does I can see that it never gets to using ido since the
last condition below is false:
org.el:10147-10150 (package repository version 20131028):
    (if (and org-completion-use-ido
         (fboundp 'ido-completing-read)
         (boundp 'ido-mode) ido-mode
         (listp (second args)))

This is not strange, since org-icompleting-read is called like this in

                (org-icompleting-read "Tags: "
                          nil nil current 'org-tags-history))))))
Hmm, shouldn't that 'org-tags-completion-function be replaced with
org-last-tags-completion-table? A quick test shows that works, and from
glancing at the code it seems like org-last-tags-completion-table should
hold the proper assortment of tags...


ido apparently needs a list of possible completions, not a single symbol.

I don't understand much more of this really.
Is it a bug? Have I misunderstood something?

Anders Johansson

Reply via email to