org-super-agenda icon indicating copy to clipboard operation
org-super-agenda copied to clipboard

Example configuration should use setq

Open tenpast opened this issue 6 years ago • 12 comments

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:

  1. Install org-super-agenda from Melpa.
  2. Paste the following code into my init file: (let ((org-super-agenda-groups '((:auto-category t)))) (org-agenda-list))
  3. 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!

tenpast avatar Sep 19 '18 13:09 tenpast

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 avatar Sep 19 '18 19:09 alphapapa

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

alphapapa avatar Sep 19 '18 19:09 alphapapa

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 avatar Sep 20 '18 02:09 tenpast

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 avatar Sep 20 '18 02:09 alphapapa

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

tenpast avatar Sep 20 '18 02:09 tenpast

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

alphapapa avatar Nov 18 '18 07:11 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 - 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 avatar Nov 27 '18 20:11 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

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.

alphapapa avatar Nov 28 '18 02:11 alphapapa

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

Syncriix avatar Nov 28 '18 17:11 Syncriix

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.

alphapapa avatar Nov 29 '18 05:11 alphapapa

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 avatar Feb 26 '19 12:02 rieje

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

alphapapa avatar Mar 04 '19 03:03 alphapapa