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: "
'org-tags-completion-function
nil nil current 'org-tags-history)))))
Cheers,
Anders Johansson
2013-11-01 02:33, Eric Abrahamsen skrev:
Anders Johansson <mejlaande...@gmail.com> writes:
Greetings,
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-set-tags:
org.el:14519-14521
(org-icompleting-read "Tags: "
'org-tags-completion-function
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...
E
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?
Greetings,
Anders Johansson
