On Jun 30, 2011, at 2:40 PM, Nick Dokos wrote: > Bastien <b...@altern.org> wrote: > >> Hi Sebastian, >> >> "Sebastien Vauban" <wxhgmqzgw...@spammotel.com> writes: >> >>> When I was trying to refile an extract of an email, I got this: >>> >>> Getting targets...done >>> funcall: Symbol's function definition is void: partial-completion-mode >> >> thanks for reporting this -- this is indeed something wrong with the fix >> I made to `org-without-partial-completion' (see my other message to Paul >> Sexton). >> >> I reverted his patch so you won't see this error again. >> > > I'm not sure that't the problem though: the org-without-partial-completion > macro is called in a couple of places, once in org-remember.el and twice > in org.el. I'm not sure how many people still use org-remember, but I suspect > quite a few. The macro basically says: execute the body while mmaking sure > that partial-completion-body is off during the execution. At least, that's > the intent but I haven't thought through the quoting change that Paul made. > > The calls: > > o org-remember-apply-template: called in the g or G case to complete tags. > o org.el: in org-icompleting-read.
> o org.el: in org-set-tags *around* org-icompleting-read. > > The last one seems superfluous at first sight, but I haven't thought about > it yet. Yes, this one is superfluous. > > In any case, these seem fairly common situations so I think it is likely > that the macro has been called hundreds of times (over the whole org > population) > without ill effects. > > OTOH, partial-completion-mode is called explicitly in org-refile-get-location, > like this: > > (partial-completion-mode nil) This is not a function-calling form, but this is part of a let form, so it just sets the variable partial-completion-mode to nil. In effect, this does indeed turn off partial-completion-mode for the body of the form. > > Could it be that it is really meant to turn *off* partial completion mode? > In which case, it would be better to call the org-without-partion-completion > macro here to do the work. > > In any case, this explicit call seems to be more problematic than the macro. > After all that's what Seb hit. > > Nick > > - Carsten
