William,

Thanks, this has now been fixed, and the code that works is:

(setq org-agenda-custom-commands
      '(
        ("d" todo #("DELEGATED") nil)
        ("c" todo #("DONE|DEFERRED|CANCELLED") nil)
        ("w" todo #("WAITING") nil)
        ("W" agenda "" ((org-agenda-ndays 21)))
        ("A" agenda "" ((org-agenda-skip-function
                           (lambda nil (org-agenda-skip-entry-if (quote
notregexp) "\\=.*\\[#A\\]")))
                        (org-agenda-ndays 1)
                        (org-agenda-overriding-header "Today's Priority #A
tasks: ")))
        ("u" alltodo "" ((org-agenda-skip-function
                          (lambda nil (org-agenda-skip-entry-if (quote
scheduled) (quote deadline)
                                                                (quote
regexp) "<[^>\n]+>")))
                         (org-agenda-overriding-header "Unscheduled TODO
entries: ")))))


I got some help sent directly to me, didn't realise it wasn't on the list
and then go t side tracked into other bits that didn't work.

But the backtrace info is useful to have.

Thanks,

Graham

On 14/12/2007, William Henney <whenney@gmail.com> wrote:
>
> Hi Graham
>
> On Dec 13, 2007 1:11 PM, Graham Smith <myotisone@gmail.com> wrote:
> > I have been using the set up provided by John Wiegley on a Mac and have
> > tried to to use it with Emacs32 wbut with some problems as the
> > custom-set-variables command seemed to badly interact with the Emacs32w
> > custom-set-variables.
> >
>
> I have no specific help to offer, but you should be able to narrow
> down the problem further by turning on debugging of your init file.
> Starting from a unix command line, this would be "emacs --debug-init
> &", but I have no idea whether this would work on windows. If you
> can't work out how to do this on windows, you could use a more
> roundabout method as follows:
>
> 1. temporarily remove/comment the problematic code from your .emacs
> and put it in a separate file, say "bad-code.el"
> 2. restart emacs
> 3. turn on debugging with
>    M-x set-variable RET debug-on-error RET t RET
> 4. evaluate the problematic code by doing
>    M-x load-file RET path/to/bad-code.el RET
>
> In principle, either of these methods should give you a lisp backtrace
> indicating exactly what the offending command is. Even if you don't
> understand the backtrace, it might help someone else to diagnose your
> problem.
>
> Cheers
>
> Will
>
>
> --
>
>   Dr William Henney, Centro de Radioastronomía y Astrofísica,
>   Universidad Nacional Autónoma de México, Campus Morelia
>