Hi Robert, Robert Horn <rjh...@alum.mit.edu> writes:
> This patch fixes my problem, but indicates that there is a startup > sequencing issue that may also affect other parts of org. > > First the patch > > --- org-agenda.el~ 2012-09-12 21:24:27.000000000 -0400 > +++ org-agenda.el 2012-09-17 06:02:45.000000000 -0400 > @@ -90,7 +90,7 @@ > (defvar org-mobile-force-id-on-agenda-items) ; defined in org-mobile.el > (defvar org-habit-show-habits) ; defined in org-habit.el > (defvar org-habit-show-habits-only-for-today) > -(defvar org-habit-show-all-today nil) > +(defvar org-habit-show-all-today) ; defined in org-habit.el > > ;; Defined somewhere in this file, but used before definition. > (defvar org-agenda-buffer-name "*Org Agenda*") Thanks. I've applied a patch that does not (defvar ... nil), since we only defvar here to silent the byte-compiler, not to initialize the var. The rest of my change check whether the variable has been already initialized (boundp '...) so that the agenda does not choke. > Second, the symptom > > Without this patch the emacs config shows the "show-all-today" as having > been changed outside the config process, and it is set to "nil" rather > than the setting in the .emacs file. It shows this immediately upon > startup when the config option is started and nothing else has been done. > > If I understand defvar properly, this means that the org-agenda is being > evaluated before the .emacs, which is not what I expected at all. So > either I don't understand defvar properly or the order of evaluation at > startup is not what I thought. Either way, there are possibly other > defvars that need fixing. > > Now that org-habit is part of the base org-mode, perhaps the proper fix > is to remove those three defvars. Someone who understands the startup > sequence should make that decision. This is weird. If the variable has been set through .emacs.el or the .emacs-custom.el file at startup, then defvar'ing it to nil should not do anything. (setq ahem 3) => 3 (defvar ahem nil) => ahem (eval ahem) => 3 If you don't have the above results, perhaps you should report this as an Emacs bug. Thanks, -- Bastien
