Bug in Sticky Agendas

Bug in Sticky Agendas

[Ian Dunn]

[-- Attachment #1: Type: text/plain, Size: 198 bytes --]


    I've got a few tasks that I don't want appearing in the daily agenda, so I tag them with agenda_exclude and set org-agenda-skip-function to skip any entries with that tag for my daily agenda:


[-- Attachment #2: Type: application/emacs-lisp, Size: 539 bytes --]

[-- Attachment #3: Type: text/plain, Size: 434 bytes --]


As you can see, I've got a second agenda view for my nightly checklist.  So here's my problem: the skip-function is unset if I try using the nightly view.

To reproduce:

0. Turn on sticky agendas
1. C-c a d (day view agenda)
2. C-c q (quit-window)
3. C-c a T n (Nightly view)
4. Switch back to day view agenda
5. 'r' (org-agenda-redo)

Now the excluded tasks appear in the day view agenda, whereas they didn't before.

-- 
Ian Dunn

Re: Bug in Sticky Agendas

[Ian Dunn]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

>>>>> "Ian" == Ian Dunn <dunni@gnu.org> writes:

    Ian>     I've got a few tasks that I don't want appearing in the
    Ian> daily agenda, so I tag them with agenda_exclude and set
    Ian> org-agenda-skip-function to skip any entries with that tag for
    Ian> my daily agenda:

    Ian> (defun id/org-skip-by-tag (&rest tags) (if (not (apply
    Ian> 'org-entry-has-tags-p tags)) nil (save-excursion
    Ian> (outline-next-visible-heading 1) (point))))

    Ian> (let* ((agenda-skip '(org-agenda-skip-function (lambda nil
    Ian> (id/org-skip-by-tag "agenda_exclude"))))) (setq
    Ian> org-agenda-custom-commands `(("d" "Day View" agenda ""
    Ian> ((org-agenda-span 'day) ,agenda-skip)) ("T" . "Tags View")
    Ian> ("Tn" "Nightly" tags-todo "nightly&TODO==\"TODO\""))))

    Ian> As you can see, I've got a second agenda view for my nightly
    Ian> checklist.  So here's my problem: the skip-function is unset if
    Ian> I try using the nightly view.

I went ahead and looked into this myself.  Looks like the issue is that the properties (lprops) are set using symbol properties with org-agenda-redo-command, which is buffer-local.  However, according to the elisp manual (at least for the upcoming 26.1 release), symbol properties aren't buffer-local; only the value itself is.  Thus, lprops are overridden by a new agenda.

I've created the following patch to address this.  The symbol property is used as a temporary variable, but the actual lprops are stored as a buffer-local variable to each agenda buffer.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org.diff --]
[-- Type: text/x-patch, Size: 1754 bytes --]

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index a9ebb793b..5226ef486 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -2142,6 +2142,7 @@ When nil, `q' will kill the single agenda buffer."
 (defvar org-agenda-this-buffer-is-sticky nil)
 (defvar org-agenda-last-indirect-buffer nil
   "Last buffer loaded by `org-agenda-tree-to-indirect-buffer'.")
+(defvar org-agenda-lprops nil)
 
 (defconst org-agenda-local-vars
   '(org-agenda-this-buffer-name
@@ -2170,6 +2171,7 @@ When nil, `q' will kill the single agenda buffer."
     org-agenda-filtered-by-category
     org-agenda-filter-form
     org-agenda-cycle-counter
+    org-agenda-lprops
     org-agenda-last-prefix-arg)
   "Variables that must be local in agenda buffers to allow multiple buffers.")
 
@@ -3749,6 +3751,10 @@ FILTER-ALIST is an alist of filters we need to apply when
 	      (org-uniquify org-done-keywords-for-agenda))
 	(setq org-agenda-last-prefix-arg current-prefix-arg)
 	(setq org-agenda-this-buffer-name org-agenda-buffer-name)
+	;; Don't set these until we know we're in the agenda buffer,
+	;; and we know they're valid.
+	(setq org-agenda-lprops (or org-agenda-lprops
+				    (get 'org-agenda-redo-command 'org-lprops)))
 	(and name (not org-agenda-name)
 	     (setq-local org-agenda-name name)))
       (setq buffer-read-only nil))))
@@ -7312,7 +7318,7 @@ in the agenda."
 	 (cols org-agenda-columns-active)
 	 (line (org-current-line))
 	 (window-line (- line (org-current-line (window-start))))
-	 (lprops (get 'org-agenda-redo-command 'org-lprops))
+	 (lprops org-agenda-lprops)
 	 (redo-cmd (get-text-property p 'org-redo-cmd))
 	 (last-args (get-text-property p 'org-last-args))
 	 (org-agenda-overriding-cmd (get-text-property p 'org-series-cmd))

[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
Ian Dunn

Re: Bug in Sticky Agendas

[Nicolas Goaziou]

Hello,

Ian Dunn <dunni@gnu.org> writes:

> I went ahead and looked into this myself. Looks like the issue is that
> the properties (lprops) are set using symbol properties with
> org-agenda-redo-command, which is buffer-local. However, according to
> the elisp manual (at least for the upcoming 26.1 release), symbol
> properties aren't buffer-local; only the value itself is. Thus, lprops
> are overridden by a new agenda.
>
> I've created the following patch to address this. The symbol property
> is used as a temporary variable, but the actual lprops are stored as
> a buffer-local variable to each agenda buffer.

Thank you. It looks good.

Could you send it again with a proper commit message so I can apply it?

Regards,

-- 
Nicolas Goaziou

Re: Bug in Sticky Agendas

[Ian Dunn]

[-- Attachment #1: Type: text/plain, Size: 129 bytes --]


    NG> Thank you. It looks good.

    NG> Could you send it again with a proper commit message so I can apply it?

This work?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-agenda-Fix-lprops-when-recreating-sticky-agendas.patch --]
[-- Type: text/x-patch, Size: 2272 bytes --]

From df299def392a93a2adf41ae3cd740b54382d64b0 Mon Sep 17 00:00:00 2001
From: Ian Dunn <dunni@gnu.org>
Date: Sat, 6 Jan 2018 17:29:11 -0500
Subject: [PATCH] org-agenda: Fix lprops when recreating sticky agendas

* lisp/org-agenda.el (org-agenda-lprops): New variable.
  (org-agenda-local-vars): Add it.
  (org-agenda-prepare): Set lprops from symbol property.
  (org-agenda-redo): Get lprops from variable, not property.
---
 lisp/org-agenda.el | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index c67f6e024..bf406f193 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -2145,6 +2145,7 @@ When nil, `q' will kill the single agenda buffer."
 (defvar org-agenda-this-buffer-is-sticky nil)
 (defvar org-agenda-last-indirect-buffer nil
   "Last buffer loaded by `org-agenda-tree-to-indirect-buffer'.")
+(defvar org-agenda-lprops nil)
 
 (defconst org-agenda-local-vars
   '(org-agenda-this-buffer-name
@@ -2173,6 +2174,7 @@ When nil, `q' will kill the single agenda buffer."
     org-agenda-filtered-by-category
     org-agenda-filter-form
     org-agenda-cycle-counter
+    org-agenda-lprops
     org-agenda-last-prefix-arg)
   "Variables that must be local in agenda buffers to allow multiple buffers.")
 
@@ -3752,6 +3754,10 @@ FILTER-ALIST is an alist of filters we need to apply when
 	      (org-uniquify org-done-keywords-for-agenda))
 	(setq org-agenda-last-prefix-arg current-prefix-arg)
 	(setq org-agenda-this-buffer-name org-agenda-buffer-name)
+	;; Don't set these until we know we're in the agenda buffer,
+	;; and we know they're valid.
+	(setq org-agenda-lprops (or org-agenda-lprops
+				    (get 'org-agenda-redo-command 'org-lprops)))
 	(and name (not org-agenda-name)
 	     (setq-local org-agenda-name name)))
       (setq buffer-read-only nil))))
@@ -7315,7 +7321,7 @@ in the agenda."
 	 (cols org-agenda-columns-active)
 	 (line (org-current-line))
 	 (window-line (- line (org-current-line (window-start))))
-	 (lprops (get 'org-agenda-redo-command 'org-lprops))
+	 (lprops org-agenda-lprops)
 	 (redo-cmd (get-text-property p 'org-redo-cmd))
 	 (last-args (get-text-property p 'org-last-args))
 	 (org-agenda-overriding-cmd (get-text-property p 'org-series-cmd))
-- 
2.15.1


[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
Ian Dunn

Re: Bug in Sticky Agendas

[Nicolas Goaziou]

Ian Dunn <dunni@gnu.org> writes:

>     NG> Thank you. It looks good.
>
>     NG> Could you send it again with a proper commit message so I can apply it?
>
> This work?

Perfect. Applied, thank you.

Regards,