org-super-agenda
org-super-agenda copied to clipboard
Example configuration should use setq
Hi there! First of all, thanks for the great packages and interesting Reddit posts.
I've tried org-super-agenda on a couple of occasions and have given up because for some reason as soon as I change the agenda view--for example from week to day--the Super Agenda view disappears.
I cannot get it to reappear by calling org-agenda-list, or refreshing (r) the agenda. In fact, I need to close Emacs completely and reopen, and then it works again: once.
Steps to reproduce:
- Install org-super-agenda from Melpa.
- Paste the following code into my init file: (let ((org-super-agenda-groups '((:auto-category t)))) (org-agenda-list))
- eval-buffer
On the other couple of occasions I tried different examples and fiddled around for a few hours to no avail.
I anticipate something else in my configuration must be causing this strange behaviour but I don't know how to go about finding it except through an arduous process of disabling all the init and re-enabling one bit at a time.
I thought you might have some experience with this or could at least point me in the right direction.
Thanks a lot!
Hi,
Please see the note in the readme:
Note: In order for groups to be automatically applied to all agenda buffers, org-super-agenda-groups must be set in the global scope (e.g. with setq in your init file, or using the customization interface).
If you let
-bind it, it does not persist when running new agenda commands.
Unfortunately, a lot of users like yourself encounter this issue. I don't know what else to do about it. Maybe I could write the warning in big, red, flashing letters... :)
I updated the readme to try to emphasize this point. Please let me know what you think.
Thanks a lot for your quick response!
Unfortunately, a lot of users like yourself encounter this issue. I don't know what else to do about it. >Maybe I could write the warning in big, red, flashing letters... :)
How embarrassing that I did not see it.
I updated the readme to try to emphasize this point. Please let me know what you think.
It was obvious after you pointed it out. Unfortunately, I cannot unsee it, so I cannot really judge whether it would be obvious to me if I had just landed on your readme. It's certainly clearly marked now.
As to how it could be made easier to understand for me (someone who is not an elisp coder), I suppose if the examples were ready to work that would be a real help, but I assume you must have a good reason for using 'let' as opposed to 'setq' in your examples.
It is normally easy for me to understand how a given snippet of code works, but difficult to figure out the syntax if I need to change the commands (e.g. 'let' to 'setq') as the different commands may not take the same number of arguments, etc. (as is the case here).
For example, the first thing I did after reading your answer was to go back to my config and replace 'let' by 'setq' and received an error. I then realized the syntax had to be different and removed the org-agenda-list argument from inside the setq.
This process however, was not intuitive for me. I hope this helps.
Thanks again for your help and sorry for finding this configuration so challenging.
Thanks, your perspective helps a lot. I'll improve the example configuration with a setq
one. Long term, I may try to make the customize interface work for configuring groups, which would let you do it with a GUI.
You're welcome. Time to try other examples and find a good customization! Thanks again for the great work you've done.
@tenpast Revisiting this issue, I noticed that this issue was supposedly fixed back in July by https://github.com/alphapapa/org-super-agenda/commit/799a1146e35344e31d29dcff63fed723d0e3b684 (issue #22). So the note I added in https://github.com/alphapapa/org-super-agenda/commit/b88e3bca663dd66a859aebce603cbbeec783061f:
, but in that case, the setting /will not persist across agenda commands/ (so after refreshing an agenda buffer by pressing =g=, there will be no groups).
Should be incorrect and I shouldn't have added it.
Would you please confirm that, with the latest version of the package, you can let
-bind org-super-agenda-groups
and then refresh the agenda buffer by pressing g
, and the groups which are set in the let
binding (not any globally set groups) are preserved?
Thanks.
Hey @alphapapa, first of I want to give you my utmost kudos for your work! Absolutely love the concept, and also the practical part - well at least until I press g
or r
for that matter. I do have the let
bind for org-super-agenda-groups
and it is, even with the new update I just did today, not persistent.
I would love to see the example with setq
you talked about two comments ago.
Thanks, your perspective helps a lot. I'll improve the example configuration with a
setq
one. Long term, I may try to make the customize interface work for configuring groups, which would let you do it with a GUI.
I am having troubles to get that working, my config is as follows:
(use-package org-super-agenda
:ensure t
:config
(org-super-agenda-mode))
(setq org-agenda-log-mode 1)
(let ((org-super-agenda-groups
'(;; Each group has an implicit Boolean OR operator between its selectors.
(:name "TIMELINE & HABITS" ; Optionally specify section name
:time-grid t
:habit t)
(:name "Important"
;; Single arguments given alone
:tag "URGENT"
:priority "1")
(:name "Done today"
:and (:regexp "State \"DONE\""
:log t))
(:name "Clocked today"
:log t)
;; After the last group, the agenda will display items that didn't
;; match any of these groups, with the default order position of 99
)))
(org-agenda nil "a"))
Unfortunately, a lot of users like yourself encounter this issue. I don't know what else to do about it. Maybe I could write the warning in big, red, flashing letters... :)
It took me a few days to realize this, maybe the red would be a good idea - thinking about it though, why not make the setq
approach standard?
Thanks papa!
Hey @alphapapa, first of I want to give you my utmost kudos for your work! Absolutely love the concept, and also the practical part
Thanks for the kind words. Glad it's useful for you.
- well at least until I press
g
orr
for that matter. I do have thelet
bind fororg-super-agenda-groups
and it is, even with the new update I just did today, not persistent.
Thanks, I'll have to investigate further.
I would love to see the example with
setq
you talked about two comments ago.
Just use (setq org-super-agenda-groups ...
instead of (let ((org-super-agenda-groups...
. In your config, put that inside the use-package
in the :config
section.
It took me a few days to realize this, maybe the red would be a good idea - thinking about it though, why not make the
setq
approach standard?
I don't know what you mean by "standard." It is the correct way to set the variable globally for all agenda commands. Users who only want to set it for certain agenda commands should let
-bind it instead.
I think the confusion comes from many users not knowing elisp and not understanding the difference between setq
and let
. They tend to copy and paste the example, but the example is intended as a quick way to test the package and see how it works, rather than as a permanent configuration. I should probably change the example to a suggested permanent configuration, and more advanced users can let
-bind if they need to.
Just use
(setq org-super-agenda-groups ...
instead of(let ((org-super-agenda-groups...
. In your config, put that inside theuse-package
in the:config
section.
Okey, I did the following now:
(setq org-agenda-log-mode 1)
(use-package org-super-agenda
:ensure t
:config
(org-super-agenda-mode)
(setq org-super-agenda-groups
'(;; Each group has an implicit Boolean OR operator between its selectors.
(:name "TIMELINE & HABITS" ; Optionally specify section name
:time-grid t
:habit t)
(:name "Important"
;; Single arguments given alone
:tag "URGENT"
:priority "1")
(:name "Done today"
:and (:regexp "State \"DONE\""
:log t))
(:name "Clocked today"
:log t)
;; After the last group, the agenda will display items that didn't
;; match any of these groups, with the default order position of 99
(org-agenda nil "a"))))
Sadly, now it does not even display the first time anymore.
I don't know what you mean by "standard." It is the correct way to set the variable globally for all agenda commands. Users who only want to set it for certain agenda commands should
let
-bind it instead.
So are you saying that when we bind with setq
we can no longer have individual agenda views? As in the setq
command overrides all views and with let
we can define one view for lets say C-c a a
and another one for C-c c b
?
Okey, I just figured it out while writing this: I need to remove the mapping to (org-agenda nil "a")
and now it works.
I think the confusion comes from many users not knowing e lisp and not understanding the difference between
setq
andlet
. They tend to copy and paste the example, but the example is intended as a quick way to test the package and see how it works, rather than as a permanent configuration. I should probably change the example to a suggested permanent configuration, and more advanced users canlet
-bind if they need to.
Maybe restructure the doc to reflects that there are two options of implementation:
1 - let
to modify the output of individual agenda views
Drawback is that you loose the view on refresh
(use-package org-super-agenda
:ensure t
:config
(org-super-agenda-mode)
(let ((org-super-agenda-groups
'(;; CUSTOM MODIFICATIONS HERE)
(org-agenda nil "a")
'(;; CUSTOM MODIFICATIONS HERE)
(org-agenda nil "b")
))))
2 - setq
to modify the output of all agenda views
Drawback is that you loose the ability to have different individual views
(use-package org-super-agenda
:ensure t
:config
(org-super-agenda-mode)
(setq org-super-agenda-groups
'(;; CUSTOM MODIFICATIONS HERE)
))
To be honest, I have no idea if my example are right - but I thing you get what I am going for. IMHO this would make it very easy to understand, even for beginners like me
let to modify the output of individual agenda views. Drawback is that you loose the view on refresh
AFAICT this is a bug that refreshing doesn't preserve the groups. I'll have to investigate further.
setq to modify the output of all agenda views. Drawback is that you loose the ability to have different individual views
You don't lose that ability. You can still let
-bind the variable to set the groups for an invocation of an agenda command.
Sorry for noob question, but org-super-agenda is intended to replace regular org-agenda (as opposed to acting as an alternative and you can still easily use regular org-agenda), right? I'm testing out the example in the README but I'm the barrier of entry to be a little higher than the well-written documentation suggests. I want to still be able to use regular org-agenda while testing and configuring org-super-agenda to better easy my way into a workflow. If org-super-agenda can be used alongside regular org-agenda with zero issues, perhaps bind it to a different, unused key, rather than replacing the default binding for default regular org-agenda (it seems the example replaces org-agenda as implied by using the same keybinding?).
Otherwise, if org-super-agenda should be used as a replacement, then perhaps an example that shows off parts of org-super-agenda in the beginning of the agenda followed by the exact template (or as close as possible) used by default for regular org-agenda is better--then, a noob like me can still use regular org-agenda and be productive while establishing a workflow for org-super-agenda.
@rieje It does not replace org-agenda, it complements it. Enable or disable the minor mode as desired.