emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Matt Lundin <mdl@imapmail.org>
To: emacs-orgmode@gnu.org
Subject: Re: [BUG] Infinite loop in org-agenda-show-new-time
Date: Tue, 06 Aug 2013 12:36:44 -0500	[thread overview]
Message-ID: <87txj2lo0j.fsf@fastmail.fm> (raw)
In-Reply-To: <87ob9bkd4c.fsf@gmail.com> (Nick Dokos's message of "Mon, 05 Aug 2013 18:05:07 -0400")

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

  reply	other threads:[~2013-08-06 17:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-05 15:42 [BUG] Infinite loop in org-agenda-show-new-time Matt Lundin
2013-08-05 17:13 ` Nick Dokos
2013-08-05 20:14   ` Matt Lundin
2013-08-05 22:05     ` Nick Dokos
2013-08-06 17:36       ` Matt Lundin [this message]
2013-08-06 21:35         ` Nick Dokos
2013-08-06 22:45           ` Nick Dokos
2013-08-14 15:19             ` Matt Lundin
2013-08-14 15:38               ` Nick Dokos
2013-08-10 15:06         ` Nick Dokos
2013-08-14 15:15           ` Matt Lundin
2013-08-14 15:45             ` Nick Dokos
2013-08-23  9:58               ` Carsten Dominik
2013-08-23 12:07                 ` Nick Dokos
2019-12-26 19:37                   ` Andrew Hyatt
2020-02-01  9:32                     ` Bastien
2020-02-02 15:19                       ` Andrew Hyatt
2020-02-03 19:04                         ` Bastien
2020-02-04 19:25                           ` Andrew Hyatt
2020-02-04 23:38                             ` Bastien
2020-02-05 16:34                               ` Andrew Hyatt
2020-02-05 19:50                               ` Matthew Lundin
2020-02-11  7:56                                 ` Bastien
2020-02-14  3:27                                   ` Andrew Hyatt
2020-02-14 10:02                                     ` Bastien
2020-02-17 19:20                                       ` Andrew Hyatt
2020-02-17 22:53                                         ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87txj2lo0j.fsf@fastmail.fm \
    --to=mdl@imapmail.org \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).