emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

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

  List information: https://www.orgmode.org/

* 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

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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).