[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] org-habit config tinypatch

From: Bastien
Subject: Re: [O] org-habit config tinypatch
Date: Mon, 17 Sep 2012 19:02:29 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.50 (gnu/linux)

Hi Robert,

Robert Horn <address@hidden> 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*")


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]