From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org, Greg Troxel <gdt@ir.bbn.com>
Subject: Re: observations on updating to recent org
Date: Wed, 23 Apr 2014 13:58:33 +0200 [thread overview]
Message-ID: <87ha5kmf4m.fsf@gmail.com> (raw)
In-Reply-To: <87a9bco3wo.fsf@bzg.ath.cx> (Bastien's message of "Wed, 23 Apr 2014 10:17:59 +0200")
Bastien <bzg@gnu.org> writes:
> Assuming this is just difficult, not impossible, what would be the way
> to do it?
The major difficulty is to keep an association table between headlines
in the pristine original buffer, and headlines in the copy being
exported. Note that hooks and Babel code may have deleted or added some,
or altered their contents, which means that it is theoretically
impossible to get it right.
You may want to go for an approximation, i.e., add an ID property only
for headlines or inlinetasks with either
- a TODO-like keyword,
- a SCHEDULED value,
- a DEADLINE value,
- a timestamp in their contents,
- a diary-sexp in their contents.
AFAIK, ox-icalendar only considers these for export, so you will often
end up marking a super-set of actually exported entries.
Unfortunately, this will fail if a user decides to add TODO keywords or
timestamps through hooks or Babel (e.g., in order to mark current
headline with a "today" mark).
I don't think you can limit the numbers of properties drawers created
without inserting some limitations.
> Would it be possible to emulate export first just for the sake of
> adding IDs where it's necessary?
I don't think so.
> `org-icalendar-store-UID' is `nil' by default because a value of
> `t' might be very inconvenient in some circumstances -- quoting the
> docstring:
>
> "This variable is not turned on by default because we want to avoid
> creating a property drawer in every entry if people are only playing
> with this feature, or if they are only using it locally."
I know. Though, I don't find it very inconvenient to create ID
properties everywhere once per file.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2014-04-23 11:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 17:43 observations on updating to recent org Greg Troxel
2014-04-23 6:16 ` Bastien
2014-04-23 7:47 ` Nicolas Goaziou
2014-04-23 8:17 ` Bastien
2014-04-23 11:58 ` Nicolas Goaziou [this message]
2014-05-06 9:22 ` Bastien
2014-04-23 15:55 ` Greg Troxel
2014-04-23 16:16 ` Nicolas Goaziou
2014-04-23 16:25 ` Greg Troxel
2014-04-23 16:59 ` Nicolas Goaziou
2014-04-23 19:44 ` Nicolas Goaziou
2014-04-24 12:20 ` Greg Troxel
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ha5kmf4m.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=gdt@ir.bbn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.