resheduling from agenda buffer

resheduling from agenda buffer

[Richard G Riley]

Two questions:

1) When following the instruction from the following link and
rescheduling from the agenda buffer, why do I always get

"Item scheduled for nil" in the message bufffer?

See: http://www.newartisans.com/blog_files/org.mode.day.planner.php#sec8
(briefly review upcoming week)

and

2) What is the reason behind having to manually "refresh" after a
reschedule in the agenda buffer, why does it not do it automatically?

(ps Carsten, if you are reading this I found the issue with
org-return-follows-link - it has to be set before loading Org so cant be
used in normal customization block).

Re: resheduling from agenda buffer

[Carsten Dominik]

On Sep 28, 2007, at 3:15, Richard G Riley wrote:

>
> Two questions:
>
> 1) When following the instruction from the following link and
> rescheduling from the agenda buffer, why do I always get
>
> "Item scheduled for nil" in the message bufffer?

his is just a bug, fixed now for the next version.

> 2) What is the reason behind having to manually "refresh" after a
> reschedule in the agenda buffer, why does it not do it automatically?

Initially the reason was technical.  Constructing the agenda can take
a second or more, to automatically reconstructing it after each change
forbids itself.  Just moving around a changed line can be difficult.

However, after giving up on trying to change everything live, I now
happen to think that this is in fact good.   What you really do is look
at a list of tasks and appointments, and you do want to push things
around.  I really like to be able to modify several lines before
getting a rearranged display.  For example:

- When things move around with each change I make, I constantly
   have to follow the changes with my eyes and memory, this is more
   tiring.

- I change a TODO entry to DONE.  That means it should not even be
   in the agenda anymore, and a live update would just get rid of
   the item.  If you made a mistake in marking it done, it is hard to
   find the entry back and change it back.

- I want to reschedule an item to next week.  Will the display then move
   to next week? So I need to go back to today to continue working?

Things like this.  You *do* get visual feedback that an entry has been
modified, and "r" is not hard to press.
So even if I knew how to change it, I would not want to do it.

> (ps Carsten, if you are reading this I found the issue with
> org-return-follows-link - it has to be set before loading Org so cant 
> be
> used in normal customization block).

Yes, the docstring of that variable says so.

- Carsten

Re: resheduling from agenda buffer

[Carsten Dominik]

Sorry for only repeating what was said before - I wrote this in
an airplane and was not aware how far this thread had gone.  You guys
had it all figured out.  I agree that the best solution is to provide
a proper marker in the agenda when something has moved, but only move
it with "r".

It will work like this in 5.11.  Thanks.

- Carsten

On Sep 28, 2007, at 16:07, Carsten Dominik wrote:

>
> On Sep 28, 2007, at 3:15, Richard G Riley wrote:
>
>>
>> Two questions:
>>
>> 1) When following the instruction from the following link and
>> rescheduling from the agenda buffer, why do I always get
>>
>> "Item scheduled for nil" in the message bufffer?
>
> his is just a bug, fixed now for the next version.
>
>> 2) What is the reason behind having to manually "refresh" after a
>> reschedule in the agenda buffer, why does it not do it automatically?
>
> Initially the reason was technical.  Constructing the agenda can take
> a second or more, to automatically reconstructing it after each change
> forbids itself.  Just moving around a changed line can be difficult.
>
> However, after giving up on trying to change everything live, I now
> happen to think that this is in fact good.   What you really do is look
> at a list of tasks and appointments, and you do want to push things
> around.  I really like to be able to modify several lines before
> getting a rearranged display.  For example:
>
> - When things move around with each change I make, I constantly
>   have to follow the changes with my eyes and memory, this is more
>   tiring.
>
> - I change a TODO entry to DONE.  That means it should not even be
>   in the agenda anymore, and a live update would just get rid of
>   the item.  If you made a mistake in marking it done, it is hard to
>   find the entry back and change it back.
>
> - I want to reschedule an item to next week.  Will the display then 
> move
>   to next week? So I need to go back to today to continue working?
>
> Things like this.  You *do* get visual feedback that an entry has been
> modified, and "r" is not hard to press.
> So even if I knew how to change it, I would not want to do it.
>
>> (ps Carsten, if you are reading this I found the issue with
>> org-return-follows-link - it has to be set before loading Org so cant 
>> be
>> used in normal customization block).
>
> Yes, the docstring of that variable says so.
>
> - Carsten
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477

Re: resheduling from agenda buffer

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

Richard G Riley <rileyrgdev@googlemail.com> writes:

> 1) When following the instruction from the following link and
> rescheduling from the agenda buffer, why do I always get
>
> "Item scheduled for nil" in the message bufffer?

I think this is a bug.

Try this patch (also fixing small typos.)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org.el.patch --]
[-- Type: text/x-diff, Size: 2299 bytes --]

diff -u /home/guerry/elisp/testing/org/org.el /home/guerry/elisp/testing/bzg/org.el
--- /home/guerry/elisp/testing/org/org.el	2007-09-26 21:00:50.000000000 +0200
+++ /home/guerry/elisp/testing/bzg/org.el	2007-09-28 17:09:30.000000000 +0200
@@ -2199,7 +2199,7 @@
 (defcustom org-agenda-skip-scheduled-if-done nil
   "Non-nil means don't show scheduled items in agenda when they are done.
 This is relevant for the daily/weekly agenda, not for the TODO list.  And
-it applied only to the actualy date of the scheduling.  Warnings about
+it applied only to the actually date of the scheduling.  Warnings about
 an item with a past scheduling dates are always turned off when the item
 is DONE."
   :group 'org-agenda-skip
@@ -2209,7 +2209,7 @@
   "Non-nil means don't show deadines when the corresponding item is done.
 When nil, the deadline is still shown and should give you a happy feeling.
 This is relevant for the daily/weekly agenda.  And it applied only to the
-actualy date of the deadline.  Warnings about approching and past-due
+actually date of the deadline.  Warnings about approching and past-due
 deadlines are always turned off when the item is DONE."
   :group 'org-agenda-skip
   :type 'boolean)
@@ -13327,12 +13327,13 @@
 		   ((eq what 'deadline) org-deadline-string)
 		   ((eq what 'closed) org-closed-string))
 	     " ")
-	    (org-insert-time-stamp
-	     time
-	     (or org-time-was-given
-		 (and (eq what 'closed) org-log-done-with-time))
-	     (eq what 'closed)
-	     nil nil (list org-end-time-was-given))
+	    (setq ts
+		  (org-insert-time-stamp
+		   time
+		   (or org-time-was-given
+		       (and (eq what 'closed) org-log-done-with-time))
+		   (eq what 'closed)
+		   nil nil (list org-end-time-was-given)))
 	    (end-of-line 1))
 	  (goto-char (point-min))
 	  (widen)
@@ -17133,7 +17134,7 @@
   "Dispatch agenda commands to collect entries to the agenda buffer.
 Prompts for a character to select a command.  Any prefix arg will be passed
 on to the selected command.  The default selections are:
-g
+
 a     Call `org-agenda-list' to display the agenda for current day or week.
 t     Call `org-todo-list' to display the global todo list.
 T     Call `org-todo-list' to display the global todo list, select only

Diff finished.  Fri Sep 28 17:09:42 2007

[-- Attachment #3: Type: text/plain, Size: 411 bytes --]


> 2) What is the reason behind having to manually "refresh" after a
> reschedule in the agenda buffer, why does it not do it automatically?

I think the reason is to warn you about the modification without having
to save it. Actually reschedule often happens more than once before you
need to save the modified buffers, so it makes sense to only save when
you're done with all the modification...

-- 
Bastien

[-- Attachment #4: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: resheduling from agenda buffer

[Richard G Riley]

Bastien <bzg@altern.org> writes:

> Richard G Riley <rileyrgdev@googlemail.com> writes:
>
>> 1) When following the instruction from the following link and
>> rescheduling from the agenda buffer, why do I always get
>>
>> "Item scheduled for nil" in the message bufffer?
>
> I think this is a bug.
>
> Try this patch (also fixing small typos.)
>
>
>
>> 2) What is the reason behind having to manually "refresh" after a
>> reschedule in the agenda buffer, why does it not do it automatically?
>
> I think the reason is to warn you about the modification without having
> to save it. Actually reschedule often happens more than once before you
> need to save the modified buffers, so it makes sense to only save when
> you're done with all the modification...

It doesn't really make sense because as you reschedule its easy to
forget which ones you already have rescheduled and end up trying to
reschedule an already rescheduled one. Which is exactly what happened to
me. Like other operations on the agenda it's my (noob) opinion that it
should refresh immediately or only confusion (as in this case) results.

RE: resheduling from agenda buffer

[Egli Christian (KIRO 41)]

Richard G Riley <rileyrgdev@googlemail.com> writes:

> Bastien <bzg@altern.org> writes:
> >> Richard G Riley <rileyrgdev@googlemail.com> writes:
> >> 2) What is the reason behind having to manually "refresh" after a
> >> reschedule in the agenda buffer, why does it not do it
automatically?

> > I think the reason is to warn you about the modification without
having
> > to save it. Actually reschedule often happens more than once before
you
> > need to save the modified buffers, so it makes sense to only save
when
> > you're done with all the modification...

I think the reason is the principle of least surprise. If you change the
priority of an item or reschedule it (e.g. to next week) it suddenly
disapears on you if refresh happens automatically. I usually do a
S-right a couple of times to reschedule items. Imagine what I would have
to do if refresh happened automatically. I would reschedule to the next
day then move the cursor to the next day, reschedule again, etc. I much
prefer the current behaviour.

> It doesn't really make sense because as you reschedule its easy to
> forget which ones you already have rescheduled and end up trying to
> reschedule an already rescheduled one. Which is exactly what happened
to
> me. Like other operations on the agenda it's my (noob) opinion that it
> should refresh immediately or only confusion (as in this case)
results.

I can see your case, but think of the consequences of an immediate
refresh. What happens if you reshedule a task to next week? Where should
point go? To the next task? Should the point stay on the task, i.e. move
to the next week? You open a can of worms. That's why a simple solution
is the best. It doesn't surprise the user.

HTH
Christian

Re: resheduling from agenda buffer

[Bastien]

"Egli Christian (KIRO 41)" <christian.egli@credit-suisse.com> writes:

> I think the reason is the principle of least surprise. 

Agreed. That's also why rescheduling should perhaps leave some
persistent warning in the agenda buffer (as S-left/right does).
I guess it would solve the issue Richard was concerned about.

-- 
Bastien

Re: resheduling from agenda buffer

[Richard G Riley]

Bastien <bzg@altern.org> writes:

> "Egli Christian (KIRO 41)" <christian.egli@credit-suisse.com> writes:
>
>> I think the reason is the principle of least surprise. 
>
> Agreed. That's also why rescheduling should perhaps leave some
> persistent warning in the agenda buffer (as S-left/right does).
> I guess it would solve the issue Richard was concerned about.

Most 100% certainly. See the other reply. The S-<left,right>
functionality is spot on. As a noob I believe I am more likely to spot these
inconsistencies that established users. The other reply might have been
private so I include it below:

,----
| While I can understand that, it certainly surprises the user to try and
| reschedule a task that isn't really there. I would suggest that the only
| sensible and usable and consistent thing to do is to mark it as changed
| like with the S-<left,right> .. in this case it hilites the entry as
| changed but you can continue to work on it. And then refresh (r)
| obviously moves all tasks to their correct positions while leaving the
| cursor at the current/next line.
| 
| The functionality for S-<lft,right> is perfect.
`----

Re: resheduling from agenda buffer

[Richard G Riley]

"Egli Christian (KIRO 41)" <christian.egli@credit-suisse.com> writes:

> Richard G Riley <rileyrgdev@googlemail.com> writes:
>
>> Bastien <bzg@altern.org> writes:
>> >> Richard G Riley <rileyrgdev@googlemail.com> writes:
>> >> 2) What is the reason behind having to manually "refresh" after a
>> >> reschedule in the agenda buffer, why does it not do it
> automatically?
>
>> > I think the reason is to warn you about the modification without
> having
>> > to save it. Actually reschedule often happens more than once before
> you
>> > need to save the modified buffers, so it makes sense to only save
> when
>> > you're done with all the modification...
>
> I think the reason is the principle of least surprise. If you change the
> priority of an item or reschedule it (e.g. to next week) it suddenly
> disapears on you if refresh happens automatically. I usually do a
> S-right a couple of times to reschedule items. Imagine what I would have
> to do if refresh happened automatically. I would reschedule to the next
> day then move the cursor to the next day, reschedule again, etc. I much
> prefer the current behaviour.
>
>> It doesn't really make sense because as you reschedule its easy to
>> forget which ones you already have rescheduled and end up trying to
>> reschedule an already rescheduled one. Which is exactly what happened
> to
>> me. Like other operations on the agenda it's my (noob) opinion that it
>> should refresh immediately or only confusion (as in this case)
> results.
>
> I can see your case, but think of the consequences of an immediate
> refresh. What happens if you reshedule a task to next week? Where should
> point go? To the next task? Should the point stay on the task, i.e. move
> to the next week? You open a can of worms. That's why a simple solution
> is the best. It doesn't surprise the user.

While I can understand that, it certainly surprises the user to try and
reschedule a task that isn't really there. I would suggest that the only
sensible and usable and consistent thing to do is to mark it as changed
like with the S-<left,right> .. in this case it hilites the entry as
changed but you can continue to work on it. And then refresh (r)
obviously moves all tasks to their correct positions while leaving the
cursor at the current/next line.

The functionality for S-<lft,right> is perfect.


>
> HTH
> Christian

Re: resheduling from agenda buffer

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

>> I think the reason is to warn you about the modification without having
>> to save it. Actually reschedule often happens more than once before you
>> need to save the modified buffers, so it makes sense to only save when
>> you're done with all the modification...
>
> It doesn't really make sense because as you reschedule its easy to
> forget which ones you already have rescheduled and end up trying to
> reschedule an already rescheduled one. Which is exactly what happened
> to me. Like other operations on the agenda it's my (noob) opinion that
> it should refresh immediately or only confusion (as in this case)
> results.

Two issues here: (1) whether org-mode should give you visible hints for
any change you make in the agenda buffer and (2) whether this change are
to be automatically saved.

For the first issue, this can be improved by displaying a timestamp when
a new SCHEDULED: or DEADLINE: is added (just like the visible timestamp
we have when pressing S-left/right on a headline: => <2007-09-28 ven>)

For the second issue, I still think saving the modification should not
be automated. It useful to see all the changes you made before saving
them, and maybe you would agree with this once the first issue is fixed?

-- 
Bastien

Re: resheduling from agenda buffer

[John Wiegley]

Richard G Riley <rileyrgdev@googlemail.com> writes:

> It doesn't really make sense because as you reschedule its easy to forget
> which ones you already have rescheduled and end up trying to reschedule an
> already rescheduled one. Which is exactly what happened to me. Like other
> operations on the agenda it's my (noob) opinion that it should refresh
> immediately or only confusion (as in this case) results.

One reason that I don't want it to save right away: because often when I
reschedule, I miss by a day or so, and then I can just tap some keys to get it
right where I want it.

John