serious calendar integration bug

serious calendar integration bug

[Matt Price]

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

Hi folks,

Using a recent git version of org-mode (release_7.5.209.g1a687) with a
fairly recent emacs-snapshot (20110408-1, a package from the debian
emacs-snapshot ppa, but running under ubuntu maverick), I'm having a really
terrible calendar bug -- not sure if it comes from org or from emacs, but
reporting here in case anyone else has seen it.  Attempts to insert a
timestamped schedule or deadline using C-c C-s or C-c C-d bring up an EMPTY
buffer called Calendar, while REPLACING THE CONTENTS of the active buffer
with the text of a calendar.  I had a near-catastrophic moment where I
killed what I thought was a calendar buffer, but then ended up erasing my
main reference file for all my org notes.  Has anyone seen this behaviour?
And do you think it comes form org or calendar?

Oops gotta run, thanks,

Matt

[-- Attachment #2: Type: text/html, Size: 849 bytes --]

Re: serious calendar integration bug

[David Maus]

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

At Wed, 27 Apr 2011 11:06:38 -0400,
Matt Price wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> 
> [2  <text/html; ISO-8859-1 (quoted-printable)>]
> Hi folks,
> 
> Using a recent git version of org-mode (release_7.5.209.g1a687) with a fairly recent emacs-snapshot (20110408-1, a package from the debian emacs-snapshot ppa, but running under ubuntu maverick), I'm having a
> really terrible calendar bug -- not sure if it comes from org or from emacs, but reporting here in case anyone else has seen it.  Attempts to insert a timestamped schedule or deadline using C-c C-s or C-c C-d
> bring up an EMPTY buffer called Calendar, while REPLACING THE CONTENTS of the active buffer with the text of a calendar.  I had a near-catastrophic moment where I killed what I thought was a calendar buffer,
> but then ended up erasing my main reference file for all my org notes.  Has anyone seen this behaviour?  And do you think it comes form org or calendar?

I can't reproduce this with 

GNU Emacs 24.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.24.3) of
 2011-04-08 on cigue, modified by Debian

Org-mode version 7.5 (release_7.5.211.gb0094)

I also tried with release_7.5.209.g1a687 but no luck: I created a new
Org buffer, entered a new headling and scheduling/deadlining with C-c
C-s and C-c C-d worked as expected.

Best,
  -- David

-- 
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]

serious calendar integration bug

[Matt Price]

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

forgot to reply  to the list..

---------- Forwarded message ----------
From: Matt Price <moptop99@gmail.com>
Date: Wed, Apr 27, 2011 at 6:11 PM
Subject: Re: [O] serious calendar integration bug
To: David Maus <dmaus@ictsoc.de>




On Wed, Apr 27, 2011 at 3:11 PM, David Maus <dmaus@ictsoc.de> wrote:

> At Wed, 27 Apr 2011 11:06:38 -0400,
> Matt Price wrote:
> >
> > [1  <text/plain; ISO-8859-1 (7bit)>]
> >
> > [2  <text/html; ISO-8859-1 (quoted-printable)>]
> > Hi folks,
> >
> > Using a recent git version of org-mode (release_7.5.209.g1a687) with a
> fairly recent emacs-snapshot (20110408-1, a package from the debian
> emacs-snapshot ppa, but running under ubuntu maverick), I'm having a
> > really terrible calendar bug -- not sure if it comes from org or from
> emacs, but reporting here in case anyone else has seen it.  Attempts to
> insert a timestamped schedule or deadline using C-c C-s or C-c C-d
> > bring up an EMPTY buffer called Calendar, while REPLACING THE CONTENTS of
> the active buffer with the text of a calendar.  I had a near-catastrophic
> moment where I killed what I thought was a calendar buffer,
> > but then ended up erasing my main reference file for all my org notes.
> Has anyone seen this behaviour?  And do you think it comes form org or
> calendar?
>
> I can't reproduce this with
>
> GNU Emacs 24.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.24.3) of
>  2011-04-08 on cigue, modified by Debian
>
> Org-mode version 7.5 (release_7.5.211.gb0094)
>
> I also tried with release_7.5.209.g1a687 but no luck: I created a new
> Org buffer, entered a new headling and scheduling/deadlining with C-c
> C-s and C-c C-d worked as expected.
>
>
hmm.  There's definitely something funny going on, I presume with emacs
rather than org, and (again presumably) something to do with my configs or
installed packages. The function that's failing is org-eval-in-calendar:

 debug(error (wrong-type-argument window-live-p nil))
  select-window(nil)
  org-eval-in-calendar(nil t)

If we look at the defun:

(defun org-eval-in-calendar (form &optional keepdate)
  "Eval FORM in the calendar window and return to current window.
Also, store the cursor date in variable org-ans2."
  (let ((sf (selected-frame))
    (sw (selected-window)))
    (select-window (get-buffer-window "*Calendar*" t))
    (eval form)
    (when (and (not keepdate) (calendar-cursor-to-date))
      (let* ((date (calendar-cursor-to-date))
         (time (encode-time 0 0 0 (nth 1 date) (nth 0 date) (nth 2 date))))
    (setq org-ans2 (format-time-string "%Y-%m-%d" time))))
    (move-overlay org-date-ovl (1- (point)) (1+ (point)) (current-buffer))
    (select-window sw)
    (org-select-frame-set-input-focus sf)))

-------
I think emacs is having trouble finding the buffer '*Calendar*' -- even
though it clearly exists and can be manually selected using C-x b.  I could
verify this by just eval-defun'ing this line:
(select-window (get-buffer-window "*Calendar*" t))

from the scratch buffer -- this produces the same backtrace.  However,
oddly, after experiencing the same issue about 6 times in a row, the problem
mysteriously disappeared just now, and the procedure is working fine.  I
have no idea what the issue is there -- I'll report when I find it again.
Maybe someone on the list can give me suggestions for debugging if it shows
up again?  Thanks,

Matt

Best,
>  -- David
>
> --
> OpenPGP... 0x99ADB83B5A4478E6
> Jabber.... dmjena@jabber.org
> Email..... dmaus@ictsoc.de
>

[-- Attachment #2: Type: text/html, Size: 4673 bytes --]

Re: serious calendar integration bug

[Nick Dokos]

Matt Price <moptop99@gmail.com> wrote:

> hmm.  There's definitely something funny going on, I presume with emacs rather than org, and (again
> presumably) something to do with my configs or installed packages. The function that's failing is
> org-eval-in-calendar:
> 
>  debug(error (wrong-type-argument window-live-p nil))
>   select-window(nil)
>   org-eval-in-calendar(nil t)
> 
> If we look at the defun:
> 
> (defun org-eval-in-calendar (form &optional keepdate)
>   "Eval FORM in the calendar window and return to current window.
> Also, store the cursor date in variable org-ans2."
>   (let ((sf (selected-frame))
>     (sw (selected-window)))
>     (select-window (get-buffer-window "*Calendar*" t))
>     (eval form)
>     (when (and (not keepdate) (calendar-cursor-to-date))
>       (let* ((date (calendar-cursor-to-date))
>          (time (encode-time 0 0 0 (nth 1 date) (nth 0 date) (nth 2 date))))
>     (setq org-ans2 (format-time-string "%Y-%m-%d" time))))
>     (move-overlay org-date-ovl (1- (point)) (1+ (point)) (current-buffer))
>     (select-window sw)
>     (org-select-frame-set-input-focus sf)))
> 
> -------
> I think emacs is having trouble finding the buffer '*Calendar*' -- even though it clearly exists and
> can be manually selected using C-x b.  I could verify this by just eval-defun'ing this line:
> (select-window (get-buffer-window "*Calendar*" t))
> 
> from the scratch buffer -- this produces the same backtrace.  However, oddly, after experiencing the
> same issue about 6 times in a row, the problem mysteriously disappeared just now, and the procedure
> is working fine.  I have no idea what the issue is there -- I'll report when I find it again.  Maybe
> someone on the list can give me suggestions for debugging if it shows up again?  Thanks,
> 

One thing is to make sure that it is the first select-window which is failing:
there is a second one in there as well. Toggling debug-on-error and getting
a full backtrace (assuming you are loading .el files and not .elc files) would
take care of that.

If there were any concurrency, I'd suspect a race: you try to select a window
that somebody else killed in the meantime. But I don't think there is anything
like that going in emacs - but I don't know for sure.

Nick

Re: serious calendar integration bug

[Matt Price]

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

On Thu, Apr 28, 2011 at 8:43 AM, Nick Dokos <nicholas.dokos@hp.com> wrote:

> Matt Price <moptop99@gmail.com> wrote:
>
>
> One thing is to make sure that it is the first select-window which is
> failing:
> there is a second one in there as well. Toggling debug-on-error and getting
> a full backtrace (assuming you are loading .el files and not .elc files)
> would
> take care of that.
>
> If there were any concurrency, I'd suspect a race: you try to select a
> window
> that somebody else killed in the meantime. But I don't think there is
> anything
> like that going in emacs - but I don't know for sure.
>

I think I'm loading .el files, from the git repository.  And I think it must
be the first select-window failing, because  (get-buffer-window
"*Calendar*") evaluates to nil, while (selected-window) evaluates to a
numbered window.  "*scratch*" also works properly, so there's so mething
very odd about the *Calendar* window.  There must be something strange
happening with the calendar functions -- that's part of the emacs core,
right?  Or should I be worrying about my other packages?

Again, many thanks,
Matt


> Nick
>

[-- Attachment #2: Type: text/html, Size: 1737 bytes --]

Re: serious calendar integration bug

[Daniel Clemente]

El Thu, 28 Apr 2011 08:02:33 -0400 Matt Price va escriure:
>
>  debug(error (wrong-type-argument window-live-p nil))
>   select-window(nil)
>   org-eval-in-calendar(nil t)
> 

  I often experience a similar bug but with frames instead of windows:

;Debugger entered--Lisp error: (wrong-type-argument frame-live-p #<dead frame  *Minibuf-1* 0xcf00da0>)
;  frame-selected-window(#<dead frame  *Minibuf-1* 0xcf00da0>)
;  menu-bar-non-minibuffer-window-p()
;  kill-this-buffer()
;  call-interactively(kill-this-buffer nil nil)

  My solution when this happpens is: (setq menu-updating-frame nil)
  I use this for many years and it always restores Emacs and I call close buffers again. Maybe it works for you.


  I think I might also have experienced your bug: after opening another buffer from Org and messing around, my .org file was completely empty and C-x C-s would save all contents to disk. I think it was either due to vc (C-x v =) or due to the calendar when scheduling a task. Try changing focus some times: from .org to the calendar, back, etc.
  This happened about 3 or 4 weeks ago, but several times. I updated and recompiled Emacs and org and now it doesn't seem to happen. I don't have detailed information, sorry (I thought it was so severe that many people would notice it).
  My workaround: use a version control system, and execute regularly „[VCS] diff > /tmp/backup1“. And fear Emacs.


-- Daniel