Samuel Wales writes:
> nil might be a safer default?
This small feature would not be easily discovered if this option is
turned to nil, so I'd say `t' makes sense here.
But I don't feel strongly about this.
--
Bastien
nil might be a safer default?
On 11/13/13, Karl Voit wrote:
>> (setq org-agenda-search-headline-for-time nil) should do.
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
The disease DOES progress. MANY people have died from it. ANYBODY can get it.
Denmark: free Karina Hansen NOW.
* Bastien wrote:
> Hi Karl,
>
> Karl Voit writes:
>
>> I am sorry - I do not see the contradiction here.
>
> Sorry, I read too fast.
:-)
>> Why not handle each time-stamp in a consistent manner: show each
>> as whole-day items on the agenda and > ddd HH:MM> as items with an associated time (a
Hi Karl,
Karl Voit writes:
> I am sorry - I do not see the contradiction here.
Sorry, I read too fast.
> Why not handle each time-stamp in a consistent manner: show each
> as whole-day items on the agenda and ddd HH:MM> as items with an associated time (and duration)?
(setq org-agenda-sear
* Bastien wrote:
> Hi Karl,
Hi Bastien!
> Karl Voit writes:
>
>> : ** <2013-12-19 Thu 19:00-23:59> X-Mas-Party
>> :
>> : - Email-invitation received: <2013-11-13 Wed>
>
> You need to use inactive timestamps in such cases.
This is my work-around so far :-)
> From memory, we wanted to preserve
Hi Karl,
Karl Voit writes:
> : ** <2013-12-19 Thu 19:00-23:59> X-Mas-Party
> :
> : - Email-invitation received: <2013-11-13 Wed>
You need to use inactive timestamps in such cases.
>From memory, we wanted to preserve the possibility
to have multiple active timestamps in a subtree.
HTH,
--
B
Hi!
I am heavily using time-stamps. With
(setq org-agenda-skip-additional-timestamps-same-entry nil)
I see multiple time-stamps of the same heading on my agenda which I
do like very much for obvious reasons.
However, with a heading such as following I do have a problem:
: ** <2013-12-19 Th
