Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
Hello, Nikolai Weibull n...@disu.se writes: * org-agenda.el (org-agenda-maybe-redo): Test for org-agenda-this-buffer-name as well. The Agenda buffer will have a different name if it’s in sticky mode, but some commands that alter the agenda should still redo it, for example, org-agenda-remove-restriction-lock, just like org-agenda-filter-by-category does. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
Hi Nikolai, Here’s the patch again, as I don’t think the one I sent yesterday got through. My FSF papers are signed, by the way. It looks like you forgot to attach the patch... -- Bastien
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
I am so disappointed with everything that has to do with e-mail right now. For some reason the e-mail isn’t being delivered. I assume it’s not being accepted by the mailing list, but I can’t see why. I’m not getting any error message. Anyway, here’s the relevant part (and let’s see if this e-mail gets through): * org-agenda.el (org-agenda-maybe-redo): Test for org-agenda-this-buffer-name as well. The Agenda buffer will have a different name if it’s in sticky mode, but some commands that alter the agenda should still redo it, for example, org-agenda-remove-restriction-lock, just like org-agenda-filter-by-category does. --- lisp/org-agenda.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 07b77ac..5fd1cd4 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -7169,7 +7169,9 @@ in the file. Otherwise, restriction will be to the current subtree. (defun org-agenda-maybe-redo () If there is any window showing the agenda view, update it. - (let ((w (get-buffer-window org-agenda-buffer-name t)) + (let ((w (get-buffer-window (or org-agenda-this-buffer-name + org-agenda-buffer-name) + t)) (w0 (selected-window))) (when w (select-window w) -- 2.5.0 On Thu, Aug 20, 2015 at 7:21 PM, Bastien b...@gnu.org wrote: Hi Nikolai, Here’s the patch again, as I don’t think the one I sent yesterday got through. My FSF papers are signed, by the way. It looks like you forgot to attach the patch... -- Bastien
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
Here’s the patch again, as I don’t think the one I sent yesterday got through. My FSF papers are signed, by the way.
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
Hello, Nikolai Weibull n...@disu.se writes: Sorry for the late reply. Here’s a patch that should work: Thank you. Could you provide an appropriate commit message and send it using git format-patch? If you haven't signed FSF papers yet, you also need to add TINYCHANGE at the end of the commit message. Regards, -- Nicolas Goaziou
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
On Mon, Jan 19, 2015 at 6:38 PM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Nikolai Weibull n...@disu.se writes: On Sun, Jan 18, 2015 at 11:39 PM, Nicolas Goaziou It could make sense, but the current behaviour is simple and consistent : always refresh manually, no exception. I don’t agree that this is consistent at all. The Agenda is refreshed when you run, for example, org-agenda-filter-by-category, which, in my mind, is similar to setting a restriction. I didn't know an exception existed. Do you want to provide a patch for this, then? Hi! Sorry for the late reply. Here’s a patch that should work: diff -u org-agenda.el.orig org-agenda.el --- org-agenda.el.orig2015-01-18 10:31:12.0 +0100 +++ org-agenda.el2015-02-15 22:25:41.0 +0100 @@ -7135,7 +7135,9 @@ (defun org-agenda-maybe-redo () If there is any window showing the agenda view, update it. - (let ((w (get-buffer-window org-agenda-buffer-name t)) + (let ((w (get-buffer-window (or org-agenda-this-buffer-name + org-agenda-buffer-name) + t)) (w0 (selected-window))) (when w (select-window w)
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
On Sun, Jan 18, 2015 at 11:39 PM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Nikolai Weibull n...@disu.se writes: I realize that you have to update it manually, but wouldn’t it make sense to have it be updated automatically when you call org-agenda-(set|remove)-restriction-lock? At least when you do so from the Agenda itself? It could make sense, but the current behaviour is simple and consistent : always refresh manually, no exception. I don’t agree that this is consistent at all. The Agenda is refreshed when you run, for example, org-agenda-filter-by-category, which, in my mind, is similar to setting a restriction.
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
Nikolai Weibull n...@disu.se writes: On Sun, Jan 18, 2015 at 11:39 PM, Nicolas Goaziou It could make sense, but the current behaviour is simple and consistent : always refresh manually, no exception. I don’t agree that this is consistent at all. The Agenda is refreshed when you run, for example, org-agenda-filter-by-category, which, in my mind, is similar to setting a restriction. I didn't know an exception existed. Do you want to provide a patch for this, then? Regards,
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
On Sun, Jan 18, 2015 at 11:26 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Nikolai Weibull n...@disu.se writes: I’m bumping this again, as this feels like a bug and I’m surprised that no one has at least responded to it. On Wed, Jan 7, 2015 at 6:51 PM, Nikolai Weibull n...@disu.se wrote: Hi! Anyone else experiencing this? Or is my configuration wrong in some way? On Mon, Dec 22, 2014 at 7:10 PM, Nikolai Weibull n...@disu.se wrote: Hi! It seems that agendas created when org-agenda-sticky-mode is t aren’t automatically redone when calling org-agenda-(set|remove)-restriction-lock. The reason is that (org-agenda-maybe-redo) checks whether there’s a window displaying a buffer named org-agenda-buffer-name. Org-agenda-buffer-name is, for some reason, not set to the (buffer-name) for these sticky agendas (which get the key that was selected as a suffix, for example, “*Org Agenda(p)*”). I don’t know whether there’s a reason for this, but it seems like it’s a bug. Either org-agenda-buffer-name isn’t being set correctly or (org-agenda-maybe-redo) should be using (buffer-name) instead of org-agenda-buffer-name. If there’s a reason for this, I’d really like to know what it is, so that I can begin to try to remember to press g whenever I’ve updated the restriction lock. According to the manual I realize that you have to update it manually, but wouldn’t it make sense to have it be updated automatically when you call org-agenda-(set|remove)-restriction-lock? At least when you do so from the Agenda itself?
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
I’m bumping this again, as this feels like a bug and I’m surprised that no one has at least responded to it. On Wed, Jan 7, 2015 at 6:51 PM, Nikolai Weibull n...@disu.se wrote: Hi! Anyone else experiencing this? Or is my configuration wrong in some way? On Mon, Dec 22, 2014 at 7:10 PM, Nikolai Weibull n...@disu.se wrote: Hi! It seems that agendas created when org-agenda-sticky-mode is t aren’t automatically redone when calling org-agenda-(set|remove)-restriction-lock. The reason is that (org-agenda-maybe-redo) checks whether there’s a window displaying a buffer named org-agenda-buffer-name. Org-agenda-buffer-name is, for some reason, not set to the (buffer-name) for these sticky agendas (which get the key that was selected as a suffix, for example, “*Org Agenda(p)*”). I don’t know whether there’s a reason for this, but it seems like it’s a bug. Either org-agenda-buffer-name isn’t being set correctly or (org-agenda-maybe-redo) should be using (buffer-name) instead of org-agenda-buffer-name. If there’s a reason for this, I’d really like to know what it is, so that I can begin to try to remember to press g whenever I’ve updated the restriction lock. Thanks!
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
Hello, Nikolai Weibull n...@disu.se writes: I’m bumping this again, as this feels like a bug and I’m surprised that no one has at least responded to it. On Wed, Jan 7, 2015 at 6:51 PM, Nikolai Weibull n...@disu.se wrote: Hi! Anyone else experiencing this? Or is my configuration wrong in some way? On Mon, Dec 22, 2014 at 7:10 PM, Nikolai Weibull n...@disu.se wrote: Hi! It seems that agendas created when org-agenda-sticky-mode is t aren’t automatically redone when calling org-agenda-(set|remove)-restriction-lock. The reason is that (org-agenda-maybe-redo) checks whether there’s a window displaying a buffer named org-agenda-buffer-name. Org-agenda-buffer-name is, for some reason, not set to the (buffer-name) for these sticky agendas (which get the key that was selected as a suffix, for example, “*Org Agenda(p)*”). I don’t know whether there’s a reason for this, but it seems like it’s a bug. Either org-agenda-buffer-name isn’t being set correctly or (org-agenda-maybe-redo) should be using (buffer-name) instead of org-agenda-buffer-name. If there’s a reason for this, I’d really like to know what it is, so that I can begin to try to remember to press g whenever I’ve updated the restriction lock. According to the manual By default, Org maintains only a single agenda buffer and rebuilds it each time you change the view, to make sure everything is always up to date. If you often switch between agenda views and the build time bothers you, you can turn on sticky agenda buffers or make this the default by customizing the variable ‘org-agenda-sticky’. With sticky agendas, the agenda dispatcher will not recreate agenda views from scratch, it will only switch to the selected one, and you need to update the agenda by hand with ‘r’ or ‘g’ when needed. You can toggle sticky agenda view any time with ‘org-toggle-sticky-agenda’. So the whole point of sticky agenda is that you need to update it manually. Regards, -- Nicolas Goaziou
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
Nikolai Weibull n...@disu.se writes: I realize that you have to update it manually, but wouldn’t it make sense to have it be updated automatically when you call org-agenda-(set|remove)-restriction-lock? At least when you do so from the Agenda itself? It could make sense, but the current behaviour is simple and consistent : always refresh manually, no exception. The other solution is to have all actions started from the agenda trigger an automatic update. I don't know if that's the spirit of the original sticky agenda feature, but it is certainly more work for little benefit. Regards,
Re: [O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
Hi! Anyone else experiencing this? Or is my configuration wrong in some way? On Mon, Dec 22, 2014 at 7:10 PM, Nikolai Weibull n...@disu.se wrote: Hi! It seems that agendas created when org-agenda-sticky-mode is t aren’t automatically redone when calling org-agenda-(set|remove)-restriction-lock. The reason is that (org-agenda-maybe-redo) checks whether there’s a window displaying a buffer named org-agenda-buffer-name. Org-agenda-buffer-name is, for some reason, not set to the (buffer-name) for these sticky agendas (which get the key that was selected as a suffix, for example, “*Org Agenda(p)*”). I don’t know whether there’s a reason for this, but it seems like it’s a bug. Either org-agenda-buffer-name isn’t being set correctly or (org-agenda-maybe-redo) should be using (buffer-name) instead of org-agenda-buffer-name. If there’s a reason for this, I’d really like to know what it is, so that I can begin to try to remember to press g whenever I’ve updated the restriction lock. Thanks!
[O] Sticky agendas not redone when using org-agenda-(set|remove)-restriction-lock
Hi! It seems that agendas created when org-agenda-sticky-mode is t aren’t automatically redone when calling org-agenda-(set|remove)-restriction-lock. The reason is that (org-agenda-maybe-redo) checks whether there’s a window displaying a buffer named org-agenda-buffer-name. Org-agenda-buffer-name is, for some reason, not set to the (buffer-name) for these sticky agendas (which get the key that was selected as a suffix, for example, “*Org Agenda(p)*”). I don’t know whether there’s a reason for this, but it seems like it’s a bug. Either org-agenda-buffer-name isn’t being set correctly or (org-agenda-maybe-redo) should be using (buffer-name) instead of org-agenda-buffer-name. If there’s a reason for this, I’d really like to know what it is, so that I can begin to try to remember to press g whenever I’ve updated the restriction lock. Thanks!
