search

insanum / gcalcli

Google Calendar Command Line Interface
MIT License
3.3k stars 311 forks source link

--details is broken for --tsv #435

Closed mumpitzstuff closed 5 years ago

mumpitzstuff commented 5 years ago

--details all: does not work (not all details are visible e.g. longurl and other details)

if --details all is active all other --details parameters are ignored like --details longurl

lasers commented 5 years ago

@jcrowgey See if you like this fix https://github.com/lasers/gcalcli/tree/longurl

EDIT: Actually... The urls disappears on me after a while. Use url instead.

jcrowgey commented 5 years ago

I'm not sure I fully understand the intended semantics. I believe that the shift from many detailX args to a single --details flag has shifted the ground underneath us a bit and we are in a bit of a weird state. Currently gcalcli add --h uses the details parser, which has the help message saying "which parts of to display", but we don't display the event when adding it. So I think that's already a little wrong.

I think the long/short was originally intended to be used in add to use the url shortening service (or not). I don't currently have any events with urls on my calendar so i'm not able to test this at the moment. Fill in here if you have information.

lasers commented 5 years ago

I think the long/short was originally intended to be used in add to use the url shortening service (or not).

I think it's for outputting in gcalcli agenda and the likes. From what I see, you have an option of using long/short url. If you specified short, then it have to shorten the urls repeatedly with new hashes. With long url, it will repeatedly display the same urls. Longurl could be preferable in most scenarios and to use shorturl when you want to share.

I don't currently have any events with urls on my calendar... Fill in here if you have information.

Does this work for you?

jcrowgey commented 5 years ago

Got it yes, that makes sense. I think I didn't realize that the Link attribute was generated automatically. So, do we agree that the --detail parser probably isn't appropriate for add?

(sorry that's a bit off topic from this issue, but I couldn't help but notice that we have the detail parser available for add)

Regarding the actually reported issue, I've reproduced it, sorry I was slow on this one. Thanks for the fix, @lasers. I'm actually want to do something a little different than what you've got, please take a look at the PR I created from your branch and let me know what you'd like to do. Thanks again!

lasers commented 5 years ago

So, do we agree that the --detail parser probably isn't appropriate for add?

I think so because Which parts to display, can be:... does not make sense to be there.