PT writes:
> [Orgmode] org-read-date-prefer-future 'time doesn't always prefer future
>
> This is a very useful setting, because it allows the user to
> quickly schedule a task into the future by simply entering the
> time, but it doesn't always do the right thing.
>
> Suppose I scheduled a task to 1pm, but I didn't have time to deal
> with it during the day. It's 5pm now. If I want to reschedule the task to
> tomorrow 10am then I can write simply 10am to the time prompt and
> it puts the task correctly to tomorrow 10am. However, if I want
> to reschedule it to tomorrow 2pm then I can't write simply 2pm,
> because then it schedules the task at 2pm today (which is past
> already, since it's 5 pm).
>
> The problem is the feature uses the task's own scheduled time to
> determine if a time is in the past, instead of the current time.
>
>
> It's Org-mode version 6.33
Skip clocking out when we are clocking in the same task that
is currently clocking but go through the normal clock-in
setup so a modified task name or effort property is
updated in the modeline.
Avoid closing the currently clocking entry when clocking in the same task
again. Leave the clock entry open until some other task is clocked in.
This allows us to clock in tasks with hooks that are called frequently without
generating lots of short sequential clock entries for the same task.
Matt Lundin writes
> I believe that commit b8e0d6fdb4 broke
> accessing timestamps with the org-entry-get.
>
> With that commit, several functions I use to check whether an entry has
> a timestamp stopped working.
>
> In other words,
>
> (org-entry-get nil "TIMESTAMP_IA")
>
> or
>
> (org-entry-get nil "TIMESTAMP")
>
> always return nil, even if a timestamp exists.
>
> Strangely, the org-entry-properties alist includes values for TIMESTAMP
> and TIMESTAMP_IA.
>
> I tested this by evaluating the expressions in the sample entry below:
>
> --8<---------------cut here---------------start------------->8---
> * TODO Test 💻
> <2009-12-19 Sat>
> [2009-12-19 Sat 17:47]
>
> (org-entry-get nil "TIMESTAMP_IA")
> (org-entry-get nil "TIMESTAMP")
> (org-entry-properties)
> --8<---------------cut here---------------end--------------->8---
The regular expression was not optimal, and if there was a horizontal
rule, search would not start from the beginning of the buffer but from
after the rule!
Samuel Wales writes:
> I found three places where the lowercase version of a todo
> kw is treated specially in the latest org. For example,
>
> * todo this is lowercase
>
> First, in the agenda, they have a special face.
>
> Second, when inserting an id link, they are removed.
>
> Third, when printing the olpath, they are removed. To
> reproduce, place point at bol on 5 and press the spacebar.
> I expect todo to be in the olpath, but it is not.
>
> Thanks.
>
>
> Samuel
>
>
> * 1
> *** 2
> ***** here are some keywords i like
> ******* todo
> ********* 5
When an agenda custom command has an empty string as MATCH element, so
far this would lead to a meaningless search using an empty matcher.
Now and empty (or white) string will be interpreted just like a nil
matcher, i.e. the user will be prompted for the match.
David Maus writes:
> Just realized that there a lot of broken links in the published
> version of Worg. Seems like something went totally wrong with the
> export to html. For instance:
>
> http://orgmode.org/worg/
>
> "The main resources"
>
> The link to the official page reads http:/g and leads to
> http://orgmode.org/worg/g
>
> -or-
>
> http://orgmode.org/worg/org-contrib/org-protocol.php
>
> "Firefox"
>
> As of March 2009 Firefox users follow the steps documented on
> http:l. Here is a summary: ...
>
> the link reads "http:l" and leads to
> http://orgmode.org/worg/org-contrib/l
>
> And so on.
>
Carsten Dominik
Bernt Hansen
John Wiegley