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