Re: [emacs-wiki-discuss] Re: Help request for planner-multi: cyclic saves

[Angus Lees]

At Thu, 24 Mar 2005 21:28:13 +0800, Sacha Chua wrote:
> sf writes:
> >   make-extent(1633 1633 nil)
> >   # bind (buffer epos spos)
> 
> Okay, that's just weird! Is this a font-locking thing? Let me check
> on the mailing list..
> 
> Are any XEmacs users who use both planner-multi and planner-id
> having problems with planner-sort-tasks having a backtrace that ends
> with make-extent?

I don't use planner-multi and its been a while since I fixed it so I
don't remember what the backtrace looked like.

I found in XEmacs (21.4.17), I had to change planner-id-find-task to
avoid the regexp "\\s-+.*?" - somehow xemacs parses that wrong.
Grouping the .*? seemed to fix things:

(defun planner-id-find-task (task-info &optional point)
  "Find task described by TASK-INFO. If POINT is non-nil, start from there.
If task is found, move point to line beginning and return non-nil.
If task is not found, leave point at POINT or the start of the buffer
and return nil."
  (goto-char (or point (point-min)))
  (let ((task-id (planner-id-get-id-from-string
                  (planner-task-description task-info))))
    (when (re-search-forward
           (concat
            "#[A-C][0-9]*\\s-+.\\s-+"
            (if task-id
                (concat "\\(?:.*?\\)" (regexp-quote 
(planner-id-format-as-string task-id)))
              (regexp-quote (planner-task-description task-info)))) nil t)
      (goto-char (line-beginning-position)))))


Now I just have to find the bug that makes me have to kill xemacs
every morning - somehow generating a new planner page and moving tasks
onto it gets into an endless (un-C-g-able) loop.  Recent (stable)
releases of planner seem to have had more XEmacs problems than I'm
used to fwiw.

-- 
 - Gus