emacs-orgmode
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]