Hi Karl,
Karl Voit writes:
> Remark regarding the order of the two entries: the last thing that
> gets added/modified is always the last one in this line. So if I
> create SCHEDULED and DEADLINE, DEADLINE is the second (last) in the
> line. When I modify SCHEDULED afterwards, it is SCHEDULED tha
Hi Nick,
Nick Dokos writes:
> The other thing that I *think* I ran into is that occasionally, with a
> DEADLINE and SCHEDULED on the same line, changing one would change the
> *order*. I did wonder whether org was chronologically ordering them, but
> that was not the case.
It is now -- most re
I want to enforce a policy of having SCHEDULED, DEADLINED and CLOSED
always on the *same line* -- which is the default behavior when using
the command.
Would that break too many .org files?
--
Bastien
Sebastien Vauban wrote:
> Hi Nick,
>
> Nick Dokos wrote:
> > Bastien wrote:
> >> Okay, I've pushed another fix.
> >>
> >> This let me stumble upon another case: the one with org-schedule and
> >> org-deadline ignoring warning cookies -- these cases are also fixed.
> >>
> >> Please confirm!
>
I checked out via «git pull», re-compiled Org-mode and tested again:
this time, all my test cases mentioned in the original posting
worked fine. Bug fixed so far.
* Nick Dokos wrote:
>
> There is a peculiar corner case:
>
> If I have a headline that's both scheduled and deadlined, like this:
>
>
Hi Sebastien,
"Sebastien Vauban" writes:
> See http://www.mail-archive.com/emacs-orgmode@gnu.org/msg37987.html where I
> report such a case with inactive timestamps and SCHEDULED dates.
>
> See Bastien's answer in the same thread. In this case, SCHEDULED should come
> first, before DEADLINE, for
Hi Nick,
Nick Dokos wrote:
> Bastien wrote:
>> Okay, I've pushed another fix.
>>
>> This let me stumble upon another case: the one with org-schedule and
>> org-deadline ignoring warning cookies -- these cases are also fixed.
>>
>> Please confirm!
>
> Confirmed. There is a peculiar corner case:
Bastien wrote:
> Okay, I've pushed another fix.
>
> This let me stumble upon another case: the one with org-schedule and
> org-deadline ignoring warning cookies -- these cases are also fixed.
>
> Please confirm!
>
Confirmed. There is a peculiar corner case:
If I have a headline that's both s
Okay, I've pushed another fix.
This let me stumble upon another case: the one with org-schedule and
org-deadline ignoring warning cookies -- these cases are also fixed.
Please confirm!
Thanks,
--
Bastien
Bastien wrote:
> Hello Karl,
>
> Karl Voit writes:
>
> > Sorry when I disagree for one case:
> >
> > When I change each entry in my test data using «C-c .» and clicking
> > on 1st of July ...
> >
> > ,[ test data ]
> > | <2011-06-28 Tue>
> > | <2011-06-28 Tue +1w>
> > | <2011-06-28 Tue -1d
Hello Karl,
Karl Voit writes:
> Sorry when I disagree for one case:
>
> When I change each entry in my test data using «C-c .» and clicking
> on 1st of July ...
>
> ,[ test data ]
> | <2011-06-28 Tue>
> | <2011-06-28 Tue +1w>
> | <2011-06-28 Tue -1d>
> | <2011-06-28 Tue +1w -1d>
> `
>
>
* Bastien wrote:
> Karl Voit writes:
>
>> The warning period still gets deleted though :-(
>
> You're right, should be fixed now.
Sorry when I disagree for one case:
When I change each entry in my test data using «C-c .» and clicking
on 1st of July ...
,[ test data ]
| <2011-06-28 Tue>
| <
Karl Voit writes:
> The warning period still gets deleted though :-(
You're right, should be fixed now.
Thanks!
--
Bastien
* Nick Dokos wrote:
>
> Do you use compiled (.elc) files?
Not intentionally.
> If so, you need to "make clean; make" before restarting. You can
> also check with
This one did the trick. Thanks!
--
Karl Voit
After re-compiling my elc files, I have now the following behavior:
* Karl Voit wrote:
>
> created timestamp with «C-c .»
> <2011-06-28 Tue>
>
> modified with «C-c.» to wednesday:
> <2011-06-29 Wed>
>
> manually added repeater:
> <2011-06-29 Wed +1w>
>
> «C-c .» + click on Jul 5th:
<2011-07-05 T
Karl Voit wrote:
> * Bastien wrote:
> > Karl Voit writes:
> >
> >> -> repeater and warning period is lost :-(
> >
> > I cannot reproduce this.
> > Did you take care of loading the freshly pulled Org version?
>
> «git pull» on the master and then I re-started my Emacs. I thought
> this should
Karl Voit writes:
> «git pull» on the master and then I re-started my Emacs. I thought
> this should be enough ...
If you byte-compiled the previous version of Org, Emacs will load
this one, not the fresh one.
> Or is there any setting that can conflict and produce the behavior
> of my Org-mod
Bastien wrote:
> Karl Voit writes:
>
> > -> repeater and warning period is lost :-(
>
> I cannot reproduce this.
>
> Did you take care of loading the freshly pulled Org version?
>
I can't reproduce this either. Both repeaters and warning periods
are preserved with C-c . (and with C-c C-s a
* Bastien wrote:
> Karl Voit writes:
>
>> -> repeater and warning period is lost :-(
>
> I cannot reproduce this.
> Did you take care of loading the freshly pulled Org version?
«git pull» on the master and then I re-started my Emacs. I thought
this should be enough ...
Or is there any setting
Karl Voit writes:
> -> repeater and warning period is lost :-(
I cannot reproduce this.
Did you take care of loading the freshly pulled Org version?
--
Bastien
* Bastien wrote:
> Karl Voit writes:
>
>> Same to me. Unfortunately I am using timestamps not only in the
>> context of DEADLINE or SCHEDULED but also for events that should
>> simply show up on the agenda (without deadline or scheduled
>> timestamp at all).
>>
>> To me this *is* a bug since my e
Karl Voit writes:
> Same to me. Unfortunately I am using timestamps not only in the
> context of DEADLINE or SCHEDULED but also for events that should
> simply show up on the agenda (without deadline or scheduled
> timestamp at all).
>
> To me this *is* a bug since my expected behavior of org-tim
* Michael Brand wrote:
>
> If it is a DEADLINE or SCHEDULED you can also use "C-c C-d ." or "C-c
> C-s ." as a workaround to preserve the repeater. Therefore I consider
> loosing the repeater with just "C-c ." on any active timestamp, no
> matter if a DEADLINE, SCHEDULED or not, a bug.
Same to me
23 matches
Mail list logo
