[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Orgmode] Re: bug with respect to org-read-date-prefer-future
From: |
Bernt Hansen |
Subject: |
[Orgmode] Re: bug with respect to org-read-date-prefer-future |
Date: |
Fri, 08 Oct 2010 15:50:10 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
Eric S Fraga <address@hidden> writes:
> On Fri, 08 Oct 2010 15:01:49 -0400, Bernt Hansen <address@hidden> wrote:
>>
>> Eric S Fraga <address@hidden> writes:
>>
>> > Recently, but I cannot say for how long, I have found that dates
>> > entered, for instance using "j" in the standard agenda view, no longer
>> > choose a time/day in the future but seem to default to the current
>> > year. For instance, today, typing "j 2 feb RET" (with a real space
>> > between 2 and feb) jumps me to 2010 February 2, not 2011.
>
> [...]
>
>>
>> Hi Eric,
>>
>> This was recently changed in commit
>> 03b178d (Do not prefer future when jumping to a date in the agenda,
>> 2010-09-21)
>> by Carsten after an offline discussion with me.
>>
>> The behaviour changed for the 'j' command in the agenda only but not for
>> other date prompts.
>
> Ah, okay, so I am not totally losing it... ;-)
>
>> The justification for this was at the start of a new month you need to
>> enter the year to go back to a date a week or two ago in the agenda
>> which seemed inconvenient.
>>
>> Carsten noticed that I had set org-read-date-prefer-future to nil in
>> http://doc.norang.ca/org-mode.html and questioned why that was
>> necessary. After a short discussion he decided to change the default
>> behaviour for the agenda j command only.
>>
>> Please comment on whether this change is good or bad. The docstring
>> should be more clear about this change if we decide to keep it.
>>
>> Regards,
>> Bernt
>
> Well, I must say that I prefer the old way as it is more likely (on a
> simple probabilistic view considering the full twelve months of the
> year) that I am going to want a future date if I refer to a month
> before the current one. I can understand your justification for
> earlier in a month but I typically simply use, say, -7 or -10 then (as
> I use +7 or +10 say for days in the future). So, I guess my view is
> that the change is more bad than good... At the very least, I would
> like this to be configurable, if that is at all possible? If not, I
> am sure I can adjust!
>
> By the way, I guess I could see an argument for a date alone being for
> the current month, whether future or past, much as time can be
> considered already to be for the current day, whether future or past,
> if the variable is configured as I have it (time), but even then we
> should have a configurable variable?
>
> Regardless, the docs definitely have to change!
Personally I'm okay with reverting this commit if it is problematic.
I'll leave the final decision on that up to Carsten.
-Bernt