Example configuration should use setq

[alphapapa]

Example configuration should use setq

[alphapapa]

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 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.

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.

[tenpast]

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.

[tenpast]

You're welcome. Time to try other examples and find a good customization! Thanks again for the great work you've done.

[alphapapa]

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... :)

[alphapapa]

I updated the readme to try to emphasize this point. Please let me know what you think.

[alphapapa]

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.

[alphapapa]

@tenpast Revisiting this issue, I noticed that this issue was supposedly fixed back in July by 799a114 (issue #22). So the note I added in b88e3bc:

, 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.

[Syncriix]

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!

[Syncriix]

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.

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 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.

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

[alphapapa]

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.

[rieje]

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.

[alphapapa]

@rieje It does not replace org-agenda, it complements it. Enable or disable the minor mode as desired.