[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*")
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