Bug: Extra space inserted in repeated tasks' date line

Bug: Extra space inserted in repeated tasks' date line

[Markus Berlin]

Hi,

some time ago I noticed this small bug (small but it keeps annoying me!):

If the following are set:

  (setq org-log-done 'time)
  (setq org-log-repeat nil)

then if you press C-c C-t on a repeated tasks, like this one:

* TODO do nothing
  SCHEDULED: <2011-08-12 Fr .+2d>

an extra space is introduced just before "SCHEDULED", i.e. you get:

* TODO do nothing
   SCHEDULED: <2011-08-17 Mi .+2d>
  ^

instead of what you want:

* TODO do nothing
  SCHEDULED: <2011-08-17 Mi .+2d>


I get this with the current version from git. This must have been
introduced somewhere before version 7.5, I think, but I cannot say
exactly when...

Best wishes,
Markus

Re: Bug: Extra space inserted in repeated tasks' date line

[Bastien]

Hi Markus,

Markus Berlin <ecce.berlin@googlemail.com> writes:

> some time ago I noticed this small bug (small but it keeps annoying me!):
>
> If the following are set:
>
>   (setq org-log-done 'time)
>   (setq org-log-repeat nil)
>
> then if you press C-c C-t on a repeated tasks, like this one:
>
> * TODO do nothing
>   SCHEDULED: <2011-08-12 Fr .+2d>
>
> an extra space is introduced just before "SCHEDULED", i.e. you get:
>
> * TODO do nothing
>    SCHEDULED: <2011-08-17 Mi .+2d>
>   ^
>
> instead of what you want:
>
> * TODO do nothing
>   SCHEDULED: <2011-08-17 Mi .+2d>

This is fixed in the current git repo -- please test and confirm.

Thanks,

-- 
 Bastien

Re: Bug: Extra space inserted in repeated tasks' date line

[Sebastien Vauban]

Hi Bastien and Markus,

Bastien wrote:
> Markus Berlin <ecce.berlin-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
>
>> some time ago I noticed this small bug (small but it keeps annoying me!):
>>
>> If the following are set:
>>
>>   (setq org-log-done 'time)
>>   (setq org-log-repeat nil)
>>
>> then if you press C-c C-t on a repeated tasks, like this one:
>>
>> * TODO do nothing
>>   SCHEDULED: <2011-08-12 Fr .+2d>
>>
>> an extra space is introduced just before "SCHEDULED", i.e. you get:
>>
>> * TODO do nothing
>>    SCHEDULED: <2011-08-17 Mi .+2d>
>>   ^
>>
>> instead of what you want:
>>
>> * TODO do nothing
>>   SCHEDULED: <2011-08-17 Mi .+2d>
>
> This is fixed in the current git repo -- please test and confirm.

Similar to this, I've noticed that sometimes the SCHEDULED line (or DEADLINE,
or ...) is moved synchronously with the heading when promoting/demoting,
sometimes not.

I now found in which cases it does and when it does not: it depends on the
presence of text in the entry.

So, for example:

--8<---------------cut here---------------start------------->8---
* The SCHED will be moved
  SCHEDULED: <2011-08-18 Thu>

* This one won't be moved along with the heading
  SCHEDULED: <2011-08-18 Thu>

Because of this text here...
--8<---------------cut here---------------end--------------->8---

becomes, when demoted:

--8<---------------cut here---------------start------------->8---
* New section

** The SCHED will be moved
   SCHEDULED: <2011-08-18 Thu>

** This one won't be moved along with the heading
  SCHEDULED: <2011-08-18 Thu>

Because of this text here...
--8<---------------cut here---------------end--------------->8---

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Bug: Extra space inserted in repeated tasks' date line

[Carsten Dominik]

On Aug 18, 2011, at 10:22 AM, Sebastien Vauban wrote:

> Hi Bastien and Markus,
> 
> Bastien wrote:
>> Markus Berlin <ecce.berlin@googlemail.com> writes:
>> 
>>> some time ago I noticed this small bug (small but it keeps annoying me!):
>>> 
>>> If the following are set:
>>> 
>>>  (setq org-log-done 'time)
>>>  (setq org-log-repeat nil)
>>> 
>>> then if you press C-c C-t on a repeated tasks, like this one:
>>> 
>>> * TODO do nothing
>>>  SCHEDULED: <2011-08-12 Fr .+2d>
>>> 
>>> an extra space is introduced just before "SCHEDULED", i.e. you get:
>>> 
>>> * TODO do nothing
>>>   SCHEDULED: <2011-08-17 Mi .+2d>
>>>  ^
>>> 
>>> instead of what you want:
>>> 
>>> * TODO do nothing
>>>  SCHEDULED: <2011-08-17 Mi .+2d>
>> 
>> This is fixed in the current git repo -- please test and confirm.
> 
> Similar to this, I've noticed that sometimes the SCHEDULED line (or DEADLINE,
> or ...) is moved synchronously with the heading when promoting/demoting,
> sometimes not.
> 
> I now found in which cases it does and when it does not: it depends on the
> presence of text in the entry.


It depends on the presence of *unindented* text in the entry,
and purposefully so.  See the variable `org-adapt-indentation'.

HTH

- Carsten

> 
> So, for example:
> 
> --8<---------------cut here---------------start------------->8---
> * The SCHED will be moved
>  SCHEDULED: <2011-08-18 Thu>
> 
> * This one won't be moved along with the heading
>  SCHEDULED: <2011-08-18 Thu>
> 
> Because of this text here...
> --8<---------------cut here---------------end--------------->8---
> 
> becomes, when demoted:
> 
> --8<---------------cut here---------------start------------->8---
> * New section
> 
> ** The SCHED will be moved
>   SCHEDULED: <2011-08-18 Thu>
> 
> ** This one won't be moved along with the heading
>  SCHEDULED: <2011-08-18 Thu>
> 
> Because of this text here...
> --8<---------------cut here---------------end--------------->8---
> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> 
> 

- Carsten

Re: Bug: Extra space inserted in repeated tasks' date line

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
> On Aug 18, 2011, at 10:22 AM, Sebastien Vauban wrote:
>> Bastien wrote:
>>> Markus Berlin <ecce.berlin-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
>>>> some time ago I noticed this small bug (small but it keeps annoying me!):
>>>> an extra space is introduced just before "SCHEDULED"
>> 
>> Similar to this, I've noticed that sometimes the SCHEDULED line (or
>> DEADLINE, or ...) is moved synchronously with the heading when
>> promoting/demoting, sometimes not.
>> 
>> I now found in which cases it does and when it does not: it depends on the
>> presence of text in the entry.
>
> It depends on the presence of *unindented* text in the entry,
> and purposefully so.
>
>> So, for example:
>>
>> --8<---------------cut here---------------start------------->8---
>> * The SCHED will be moved
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> * This one won't be moved along with the heading
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> Because of this text here...
>> --8<---------------cut here---------------end--------------->8---
>>
>> becomes, when demoted:
>>
>> --8<---------------cut here---------------start------------->8---
>> * New section
>>
>> ** The SCHED will be moved
>>    SCHEDULED: <2011-08-18 Thu>
>>
>> ** This one won't be moved along with the heading
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> Because of this text here...
>> --8<---------------cut here---------------end--------------->8---
>
> See the variable `org-adapt-indentation'.

This was left untouched by me, that is set to t (default), with the above
behavior.

If I change it to nil, I'm even farer from the behavior I would like to get.
In this new case:

--8<---------------cut here---------------start------------->8---
* New section

** The SCHED will be moved
  SCHEDULED: <2011-08-18 Thu>

** This one won't be moved along with the heading
  SCHEDULED: <2011-08-18 Thu>

Because of this text here...
--8<---------------cut here---------------end--------------->8---

The indentation of both SCHEDULED lines is not changed at all.

I would like that their indentation would be changed with the heading, even if
I write all my body text starting in column 0.

So, this is not currently handled, IIUC?

The SCHEDULED lines don't have a different status than the "body text" for
indentation purpose ("follow-headline" or "stay-where-you-are")?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Bug: Extra space inserted in repeated tasks' date line

[Carsten Dominik]

On Aug 18, 2011, at 11:04 AM, Sebastien Vauban wrote:

> Hi Carsten,
> 
> Carsten Dominik wrote:
>> On Aug 18, 2011, at 10:22 AM, Sebastien Vauban wrote:
>>> Bastien wrote:
>>>> Markus Berlin <ecce.berlin@googlemail.com> writes:
>>>>> some time ago I noticed this small bug (small but it keeps annoying me!):
>>>>> an extra space is introduced just before "SCHEDULED"
>>> 
>>> Similar to this, I've noticed that sometimes the SCHEDULED line (or
>>> DEADLINE, or ...) is moved synchronously with the heading when
>>> promoting/demoting, sometimes not.
>>> 
>>> I now found in which cases it does and when it does not: it depends on the
>>> presence of text in the entry.
>> 
>> It depends on the presence of *unindented* text in the entry,
>> and purposefully so.
>> 
>>> So, for example:
>>> 
>>> --8<---------------cut here---------------start------------->8---
>>> * The SCHED will be moved
>>>  SCHEDULED: <2011-08-18 Thu>
>>> 
>>> * This one won't be moved along with the heading
>>>  SCHEDULED: <2011-08-18 Thu>
>>> 
>>> Because of this text here...
>>> --8<---------------cut here---------------end--------------->8---
>>> 
>>> becomes, when demoted:
>>> 
>>> --8<---------------cut here---------------start------------->8---
>>> * New section
>>> 
>>> ** The SCHED will be moved
>>>   SCHEDULED: <2011-08-18 Thu>
>>> 
>>> ** This one won't be moved along with the heading
>>>  SCHEDULED: <2011-08-18 Thu>
>>> 
>>> Because of this text here...
>>> --8<---------------cut here---------------end--------------->8---
>> 
>> See the variable `org-adapt-indentation'.
> 
> This was left untouched by me, that is set to t (default), with the above
> behavior.
> 
> If I change it to nil, I'm even farer from the behavior I would like to get.
> In this new case:
> 
> --8<---------------cut here---------------start------------->8---
> * New section
> 
> ** The SCHED will be moved
>  SCHEDULED: <2011-08-18 Thu>
> 
> ** This one won't be moved along with the heading
>  SCHEDULED: <2011-08-18 Thu>
> 
> Because of this text here...
> --8<---------------cut here---------------end--------------->8---
> 
> The indentation of both SCHEDULED lines is not changed at all.
> 
> I would like that their indentation would be changed with the heading, even if
> I write all my body text starting in column 0.
> 
> So, this is not currently handled, IIUC?
> 
> The SCHEDULED lines don't have a different status than the "body text" for
> indentation purpose ("follow-headline" or "stay-where-you-are")?


They currently don't - but I see that this might makes sense to do differently.

- Carsten

> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> 
> 

- Carsten

Re: Bug: Extra space inserted in repeated tasks' date line

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
> On Aug 18, 2011, at 11:04 AM, Sebastien Vauban wrote:
>> Carsten Dominik wrote:
>>> On Aug 18, 2011, at 10:22 AM, Sebastien Vauban wrote:
>>>> Similar to this, I've noticed that sometimes the SCHEDULED line (or
>>>> DEADLINE, or ...) is moved synchronously with the heading when
>>>> promoting/demoting, sometimes not.
>>>> 
>>>> I now found in which cases it does and when it does not: it depends on
>>>> the presence of text in the entry.
>>> 
>>> It depends on the presence of *unindented* text in the entry,
>>> and purposefully so.
>>> 
>>>> So, for example:
>>>> 
>>>> --8<---------------cut here---------------start------------->8---
>>>> * The SCHED will be moved
>>>>  SCHEDULED: <2011-08-18 Thu>
>>>> 
>>>> * This one won't be moved along with the heading
>>>>  SCHEDULED: <2011-08-18 Thu>
>>>> 
>>>> Because of this text here...
>>>> --8<---------------cut here---------------end--------------->8---

A question: in the above headlines, as I see them in your reply, the 2 spaces
in front of SCHEDULED keyword are replaced by 1, which makes it difficult to
follow the conversation, as the example is not anymore showing what it was
supposed to.

My question is (to you or others): am I the one having the problem when
displaying your reply, or is it more on your side when answering to a post?
Don't lose time with this, but I'd like to (try to) patch this, if it's lying
on my side.

>> [...] The indentation of both SCHEDULED lines is not changed at all.
>> 
>> I would like that their indentation would be changed with the heading, even if
>> I write all my body text starting in column 0.
>> 
>> So, this is not currently handled, IIUC?
>> 
>> The SCHEDULED lines don't have a different status than the "body text" for
>> indentation purpose ("follow-headline" or "stay-where-you-are")?
>
> They currently don't - but I see that this might makes sense to do differently.

OK. Thanks for your answer.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Bug: Extra space inserted in repeated tasks' date line

[Bastien]

Hi Sébastien,

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> ** This one won't be moved along with the heading
>   SCHEDULED: <2011-08-18 Thu>
>
> Because of this text here...

This should be fixed now.  "Meta" lines (SCHEDULED string, etc, 
along with the first properties drawer) will be indented correctly,
even when text from the subtree start at the beginning of the line.

Please confirm this works okay for you, and thanks for reporting 
this!

Best,

-- 
 Bastien

Re: Bug: Extra space inserted in repeated tasks' date line

[Sebastien Vauban]

Hi Bastien,

Bastien wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>
>> ** This one won't be moved along with the heading
>>   SCHEDULED: <2011-08-18 Thu>
>>
>> Because of this text here...
>
> This should be fixed now.  "Meta" lines (SCHEDULED string, etc, 
> along with the first properties drawer) will be indented correctly,
> even when text from the subtree start at the beginning of the line.
>
> Please confirm this works okay for you, and thanks for reporting 
> this!

This works in many cases, but suffers some problems. Anyway, you're really not
far from giving this a definitive solution[1].

Here a compilation of cases which don't work, or work with an error being
generated in the echo area.

--8<---------------cut here---------------start------------->8---
* New section

The first one works, but generates an error ("setq: Wrong type argument:
number-or-marker-p, nil").

** The SCHED will be moved
   SCHEDULED: <2011-08-18 Thu>

** This one now move as well along with the heading
   SCHEDULED: <2011-08-18 Thu>

Even with this text here... but error is also generated.

Same for the following: works, with error.

** RDV client
   DEADLINE: <2011-09-06 Tue 08:30-09:15>

** Feestje Iris
   <2011-08-14 Sun 18:30>

Demoting this one does not move the active timestamp, but moves the SCHEDULED
line of the next entry.

** TODO Bi-weekly review
   SCHEDULED: <2011-08-12 Fri ++14d>
   :PROPERTIES:
   :RESET_CHECK_BOXES: t:
   :LAST_REPEAT: [2009-07-28 Tue 21:19]
   :END:

Here, the properties aren't moved. The rest well.
--8<---------------cut here---------------end--------------->8---

Thank you so much for patching this. It will save me tens of minutes per
month, and an RSI because of adding them manually? ;-)

Best regards,
  Seb

Footnotes:

[1] I've been sure for months that this worked before (like some half year
    ago), but never tried on such a vintage version. Anyway, Carsten told me I
    was wrong...

-- 
Sebastien Vauban

Re: Bug: Extra space inserted in repeated tasks' date line

[Bastien]

Hi Sébastien,

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

> This works in many cases, but suffers some problems. Anyway, you're
> really not far from giving this a definitive solution[1].

Please try latest git repo.  I should have fixed the problem you
mention. 

Thanks!

-- 
 Bastien

Re: Bug: Extra space inserted in repeated tasks' date line

[Sebastien Vauban]

Hi Bastien,

Bastien wrote:
> "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:
>
>> This works in many cases, but suffers some problems. Anyway, you're
>> really not far from giving this a definitive solution[1].
>
> Please try latest git repo. I should have fixed the problem you mention.

AFAICT, this works like a charm! Even in the case of refiling, which I did not
test yesterday -- well today!

Thanks a lot...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Bug: Extra space inserted in repeated tasks' date line

[Bastien]

"Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes:

>> Please try latest git repo. I should have fixed the problem you mention.
>
> AFAICT, this works like a charm! Even in the case of refiling, which I did not
> test yesterday -- well today!

Thanks for the quick test and confirmation!

-- 
 Bastien