From: Nick Dokos <email@example.com>
To: Bastien <firstname.lastname@example.org>
Cc: Sebastien Vauban <email@example.com>,
Subject: Re: partial-completion-mode error when refiling
Date: Thu, 30 Jun 2011 08:40:40 -0400 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: Message from Bastien <email@example.com> of "Thu, 30 Jun 2011 11:14:03 +0200." <firstname.lastname@example.org>
Bastien <email@example.com> wrote:
> Hi Sebastian,
> "Sebastien Vauban" <firstname.lastname@example.org> 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
> 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.
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
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,
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.
next prev parent reply other threads:[~2011-06-30 12:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-30 8:10 Sebastien Vauban
2011-06-30 9:14 ` Bastien
2011-06-30 12:40 ` Nick Dokos [this message]
2011-06-30 13:34 ` Carsten Dominik
2011-06-30 14:05 ` Nick Dokos
2011-06-30 15:07 ` Bastien
2011-06-30 13:35 ` Sebastien Vauban
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).