Re: org-habit config tinypatch

[Bastien <bzg@altern.org>]

Hi Robert,

Robert Horn <rjhorn@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