Open TinaRussell opened 5 years ago
Please see https://github.com/alphapapa/org-super-agenda/blob/master/notes.org#b-define-customization-types-for-group-selectors. It would be a nice feature to have, and maybe I'll do it someday. In the meantime, patches welcome.
I'm building a type analyzer into Elsa to understand the defcustom
type annotations so that would also help when people configure by hand. But it can get quite insane.
So I’ve been hacking away at this for a few days now. My progress so far is here: https://github.com/TinaRussell/org-super-agenda/tree/custom-types I’m trying to keep within the style of the existing code, adding a keyword to the group-defining macros so that each group can have its own custom-type definition.
I guess the biggest hiccups I’ve so far run into are:
order-multi
implemented? It’s the only thing in the org-super-agenda-groups
example (the one in the README, etc.) that my big ol’ custom type definition can’t understand (it displays that part as a bare sexp). I can’t find order-multi
implemented anywhere in the code, though, so I’m not sure how to make it work (or if it’s something left over in the example from an old version, etc). I appreciate your work on this, and the code in your branch looks pretty good. I like the way you added to the macros.
However, as you noted, the UI doesn't turn out great with the existing customization widgets. I noticed similar issues with some of my other packages' customization options, where it seemed difficult to read the boxes and labels, especially if any line wrapping was involved. I feel like it's actually much harder to read the structure of the sexps in the customization UI than as plain lisp code. And as you noted, displaying every possible key is a significant drawback; even though some users might find the GUI customization helpful, displaying all keys would be bewildering and cumbersome. A new widget might help, maybe one that displayed nested structures more clearly, but I also haven't used that library before, and implementing a new widget for this feels a bit out-of-scope for this project.
So I'm probably going to postpone this feature idea indefinitely. Some things are just better done as lisp code. :)
BTW, order-multi
is in the file, just search for it and you'll find the associated code.
Uh huh. I should note I did make a little bit of progress on a different widget-related front: I realized, because most of the specifiers take arguments in the form :key VALUE
or :key (VALUE VALUE …)
, I needed an easy way to have a list that’s either one item by itself or multiple items in a list. Surprisingly, I was able to make such a thing without much code: https://emacs.stackexchange.com/questions/54019/ (look for my own answer, which I’ll be allowed to accept… tomorrow, weird). I’m hoping the other UI problem (the loads of unused fields) is something I can solve, too, maybe with some hints from custom-face-edit
.
Ohhhh, I finally figured out how order-multi
works… I see, the association is set in org-super-agenda-group-transformers
. That makes sense now. Thanks!
Cool, if there were a way to simplify the widget UI, it might be worth considering. Thanks.
So, I’m pretty close to making this all work. The last piece of functionality I need to implement is the group transformers, regarding which I have an API question. I know that :order-multi
takes an integer as an argument, followed by any number of groups; if more group transformers are implemented, will they also take one argument followed by any number of groups? (Like how the auto-grouping selectors each take one argument, even if it’s just t
.) Or, is that up to how the transformer function is defined?
Probably, but I haven't given that any thought since there haven't been any more transformers.
Okay, that’s fine. The way I’m thinking is, there are two options:
All group transformers take one argument, even if just t
, followed any number of groups. A plist, org-super-agenda-group-transformer-arg-types
, will associate group transformers with custom-type specifications (for instance, integer
for :order-multi
). If a group transformer has no entry in the plist, its argument type is assumed to be (const t)
.
(more complicated, more versatile) All group transformers can potentially take any number of arguments, including none at all, followed by any number of groups. A plist, org-super-agenda-group-transformer-arg-types
, will associate group transformers with either a custom-type specification (for one leading argument) or a list of custom-type specifications (for multiple leading arguments). If a group transformer has no entry in the plist, it is assumed to take no arguments other than groups.
I don't want to commit to doing it one way or the other now. I'd recommend just doing what is necessary given the current state of the code.
I am interested to see what you've come up with, but I can't promise to merge the code in advance. I don't want to give you a false impression. I generally feel like the benefit is slight and the cost in code too heavy. In general, some parts of Org require editing Lisp code or lists, and I'm okay with that here too. It might be best if you publish your code on your own repo as an add-on, and I'd be happy to link to it in the documentation for users who are interested.
I'm currently rewriting my init.el
using the new Emacs-29 macro setopt
instead of setq
, to catch bugs due to wrong types. I found that org-super-agenda-groups
raises a type warning even if configured according to the examples (just with setopt), e.g.
(setopt org-super-agenda-groups
'((:name "Today" :time-grid t :todo "TODAY")
(:name "Important" :tag "bills" :priority "A")))
which raises
⛔ Warning (emacs): Value ‘((:name "Today" :time-grid t :todo "TODAY") (:name "Important" :tag "bills" :priority "A"))’
does not match type list.
In this particular case there is no danger in just using setq
to avoid the warning, but since the variable was declared with defcustom
, I would expect setopt
to be usable and not give warnings when used correctly.
I tested this on the Emacs master branch for Emacs 30 but I think this must be reproducable in Emacs 29.
I'm not sure if there's a simple catch-all type that can replace :type list
to avoid this warning, or if this requires actually solving this issue here and providing a specific type-definition for enabling customization widgets.
Right now,
org-super-agenda-groups
is defined like this:When you edit the option in
customize
, it looks like this:…and you can’t define the list using any customization widgets, you have to write bare Lisp syntax. I’m sure this is okay for you Emacs Lisp wizards, but to a n00b like me, it’s intimidating!
Since
org-super-agenda-groups
is a complicated (and powerful) option with its own syntax, a proper:type
definition would be a godsend! Here’s a good example of a thorough definition for a complex option with specialized syntax, fromorg-capture.el
:As the
org-super-agenda
documentation says, “At first you might feel bewildered by all the options.” The advantage of having a thorough:type
definition forcustomize
is that users can tackle one decision at a time, with the different choices clearly displayed at each juncture, without having to go back and forth between code and documentation or keep parentheses balanced or whatever, and without having to have the entire idea fully formed in one’s head from the beginning. The documentation for:type
is here: elisp: Customization Types Thanks for all your hard work! :smile: