Closed booxter closed 2 weeks ago
Wdyt about printing a note to stderr for that case (and maybe making the code a little more explicit about empty search_text for readability)?
Seems like with multiple positional args it'd be easy to have a super confusing mixup otherwise. (For example if the text is supposed to come from an env variable but it's accidentally empty.)
I don't think this should be considered an error condition, and so stderr
messages are probably not warranted. I am not sure what "making the code a little more explicit" means in this case, but perhaps we could add a special flag that would indicate that an empty value is desired. (basically, require something like: gcalcli ... search '' "today 00:00" "tomorrow 00:00" --allow-empty-query
, otherwise, fail as done right now).
I don't necessarily think this should be done (an error like what you described should probably be caught before gcalcli
is even called - by the calling party), but if you feel this is warranted, I am happy to update the patch accordingly. Let me know.
(Also, THANK YOU for the tool! In case you wonder about the use case, I am using it to generate a list of meetings for each work day, then use the list to create a separate note in my Obsidian vault per upcoming meeting. I was using icalBuddy
before for the same, but it stopped working lately.)
Some thoughts:
Comment looks like this error is designed for the case where start and end are also both unspecified so you don't get ALL events downloaded from the whole calendar, which could be pretty big.
This doesn't seem like a good use for gcalcli search
. gcalcli agenda
is what you should use when there's no search string. And its default start and end times add guardrails against getting the whole calendar. The implementation (GoogleCalendarInterface._display_queried_events()
) is the same in either case.
All that said, argparsers.get_search_parser()
gives an error if you don't specify anything, so you'll only get this if you really mean to, by submitting an empty
I'm -0 on this. It would be better to remove the search
subcommand and add a search option for agenda
instead.
Yeah, @booxter is there a reason you'd specifically want to use search
without a search string instead of agenda
? We could add a hint to the error message to use "agenda" instead, if it's just that it wasn't discoverable which command to use.
If passing an empty string was actually useful and recommended, I'd probably want to note how that works in the help text, but telling people "pass an empty string for the required positional argument" feels a little gross.
I haven't realized that agenda
can do what I need here. This PR is not needed, thanks for the pointer! :)
This allows to e.g. list all events scheduled for today with: