Re: [BUG] Infinite loop in org-agenda-show-new-time

[Matt Lundin <mdl@imapmail.org>]

Nick Dokos <ndokos@gmail.com> writes:

> So you revert that commit and the infloop goes away? I looked at the
> functions briefly and I don't understand how this commit could affect
> what move-to-column does.

Just to confirm: Did you try rescheduling with the agenda buffer
filtered only to the home tag using the sample file I provided? To
trigger the bug one must attempt to reschedule an item when 1) the
agenda is filtered by tags and 2) the item being changed contains
invisible lines immediately beneath it (b/c of the filtering). Both
these conditions are necessary to cause the bug on my end.

When the agenda buffer is filtered to a tag (i.e., when it contains
invisible lines), move-to-column treats the entire invisible region as a
single line. Moving to the end of the line moves the point to the end of
the entire invisible region.

An easy way to see this behavior in action is to do the following:

Take the following sample file (test.org):

--8<---------------cut here---------------start------------->8---
* TODO A							       :home:
  SCHEDULED: <2013-08-06 Tue>
* TODO B							       :work:
  SCHEDULED: <2013-08-06 Tue>
* TODO C							       :play:
  SCHEDULED: <2013-08-06 Tue>
--8<---------------cut here---------------end--------------->8---

1. Call the agenda restricted to that file.

--8<---------------cut here---------------start------------->8---
Day-agenda (W32):
Tuesday     6 August 2013
  test:       Scheduled:  TODO A                                          :home:
  test:       Scheduled:  TODO B                                          :work:
  test:       Scheduled:  TODO C                                          :play:
--8<---------------cut here---------------end--------------->8---

2. Narrow an agenda buffer to the tag home.

--8<---------------cut here---------------start------------->8---
Day-agenda (W32):
Tuesday     6 August 2013
  test:       Scheduled:  TODO A                                          :home:
--8<---------------cut here---------------end--------------->8---

3. Move to the beginning of the task "A" line.

4. Call either M-x move-end-of-line or M-x move-to-column 100 (or
another large number).

5. M-: (point)

On my machine the point is at 287, which is at the at the end of the
task "C" line (i.e., the end of the entire invisible region).

If I call move-end-of-line on the task "A" line when the buffer is not
filtered, the point moves to 125 - i.e., the end of the task A line.

In other words, within the agenda buffer, move-to-column and
move-end-of-line will move to the point to the end of the entire
invisible region. That is why removing the local binding of
buffer-invisibility-spec to nil triggers this bug, because when that
variable is nil, the function org-agenda-show-new-time temporarily
treats the agenda buffer as if it were visible (i.e., it ignores the
invisible overlay).

I reproduced the problem with emacs -Q, so I can confirm that it is not
a result of my configuration.

> org-move-to-column is just a compatibility function that calls
> move-to-column whose doc says:
>
>   Move point to column COLUMN in the current line.
>
> So I'm not sure why it ends up on a different line.

I think the following explains why this is happening:
(info "(elisp) Invisible Text")

,----
|    Ordinarily, functions that operate on text or move point do not care
| whether the text is invisible.  The user-level line motion commands
| ignore invisible newlines if `line-move-ignore-invisible' is non-`nil'
| (the default), but only because they are explicitly programmed to do so.
| 
|    However, if a command ends with point inside or at the boundary of
| invisible text, the main editing loop relocates point to one of the two
| ends of the invisible text.  Emacs chooses the direction of relocation
| so that it is the same as the overall movement direction of the
| command; if in doubt, it prefers a position where an inserted char
| would not inherit the `invisible' property.  Additionally, if the text
| is not replaced by an ellipsis and the command only moved within the
| invisible text, then point is moved one extra character so as to try
| and reflect the command's movement by a visible movement of the cursor.
| 
|    Thus, if the command moved point back to an invisible range (with
| the usual stickiness), Emacs moves point back to the beginning of that
| range.  If the command moved point forward into an invisible range,
| Emacs moves point forward to the first visible character that follows
| the invisible text and then forward one more character.
`----

> Can you provide emacs and org versions? Maybe there is something weird
> in what you use.

(org-version)
"Org-mode version 8.0.7 (release_8.0.7-367-gd1d918 @ /home/matt/org-mode/lisp/)"

(emacs-version)
GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.2) of 2013-07-30 on -var-lib-archbuild-staging-x86_64-jgc

(shell-command "uname -a")
Linux archdesk 3.10.3-1-ARCH #1 SMP PREEMPT Fri Jul 26 11:26:59 CEST 2013 x86_64 GNU/Linux

However, this has been a persistent problem for the last several months
(i.e., it has survived org, emacs, and system updates).

Matt