search

insanum / gcalcli

Google Calendar Command Line Interface
MIT License
3.32k stars 314 forks source link

Cannot set description and location to "" when editing events #404

Open schoettl opened 5 years ago

schoettl commented 5 years ago

Great tool, thank you!

But now I'd like to clear wrongly imported descriptions from events.

gcalcli edit --details description .

gcalcli does not change the description when I type d to change the description and type "" or " ".

I understand that this is a way to cancel the edit - but clearing the description field should be possible. Maybe by making " " (space) clearing the description? Similar like the prompt when changing reminders: Enter a valid reminder or '.' toend: (typo "toend")

Same problem applies for the location.

yulqen commented 5 years ago

Correct - we are unable to delete a description (or location) using gcalcli edit - an empty string is ignored and used to pass to the next question.

@jcrowgey - I think this should be a doable. I'm working on a fix which uses the "'.' to delete existing)" mechanism to delete the item, which I think works. The PR also includes tests. I'll submit it later this evening.

By the way, testing this code is not made any easier by the monolithic nature of gcalcli.py! I've had to do some gynmastics patching input() funcs and using environment variables to jump out of loops. Having tests is better than no tests though. I fully support the move to modularise...!

Happy to have comments when I push the PR.

jcrowgey commented 5 years ago

I think the '.' is on the right track, especially since it's already used in this program as a special symbol. What's a little weird is that in the 'enter a valid reminder or . to end' case, the '.' ends, here the '.' is a deletion. I wonder if we should switch things around so that the empty input ends the reminder loop (why do we need the . to end?), and the '.' means 'delete existing' generally in an edit loop.

yulqen commented 5 years ago

Totally see your point. I'll change the PR and we can see what it looks like.

yulqen commented 5 years ago

Grateful for views:

I would imagine that the intention would be for the edit command to be able to amend or delete all fields of an event object.

The following restraints apply -

Editable fields:

Deletable fields:

(The rest of the fields are mandatory -> title, when, duration)

Firstly, I agree that there should be consistency with the use of "." across the board - this PR uses "." to delete so far; hitting Return would pass validation, and move onto the next question.

First point: If we wanted to be consistent, we would probably have to change the add command to use the same semantics (at the moment, we use "." to end entering reminders).

Second point: currently, the code: https://github.com/insanum/gcalcli/blob/9cf983a9c785adf9abdcad88b8f2d33dc0c8d0ea/gcalcli/gcalcli.py#L1020-L1022

raises a KeyError because default_reminders, which is set to False by default in gcalcli.argparsers, is not appearing in options. I'm assuming that this is because the edit parser does not inherit the remind_parser (see below):

https://github.com/insanum/gcalcli/blob/9cf983a9c785adf9abdcad88b8f2d33dc0c8d0ea/gcalcli/argparsers.py#L238-L242

Is that correct?

In which case, I'm wondering what your view is on getting the default_reminders option into edit. As it stands (if we fix the KeyError with .get()) the default_reminders won't exist and new reminders added as part of the edit questions will not be set.

Grateful for some guidance. Thanks for taking the time!

schoettl commented 5 years ago

This idea comes pretty late as you already work on the PR. But why don't we let the user really edit the description? Currently, when the user wants to just fix a typo, he have to type the whole description again.

Wouldn't this workflow be better:

It does not work with Python's plain prompt() but it might be possible with readline and readline.insert_text(string).

I just searched for Bash's read command – this one has an option for this, but it does not work at my system.

yulqen commented 5 years ago

I like this idea. There are some interesting possibilities using readline and possibly other libraries such as prompt_toolkit.

I think the current input() based system is fairly crude and until now, it looks as though it's either been buggy or had some basic capabilities missing. I haven't been around long, but perhaps the priority has been to make the program a first class command line application, whereby all options are passed in a single line, which is where I think gcalcli has something really unique to offer (calling it from other scripts, use in database, etc) - and the prompts are a secondary fallback. Prompting the users for answers doesn't really adhere to the UNIX philosophy where the interface is kept uniform, data can be piped, etc, but done well I think it can be really user friendly.

I'm not sure what's on the maintainers' roadmap for this - it seems the priority is to fix some obvious bugs and get a new release out, and I think that's right. Also, I know @jcrowgey has done a lot of work refactoring the code and making a start on getting good tests working which is essential before lots of new features can be implemented - in its current form, without this, the code is not easy to modify thanks to much of it being monolithic in nature.

But if the indication was to go for something different here, I'd be supportive and happy to contribute ideas and code.

jcrowgey commented 5 years ago

I appreciate the content in this discussion. At the moment, as @hammerheadlemon says, my main priority is to make gcalcli extensible both as a library and as a tool. The main thing holding us back on that is modularity and testing. I am very hesitant to do feature work at this time because I want new features to fit into a cleaner system of imports and apis. This is partly selfish because although I still use google calendar at work, I'm actually not using google calendar anymore personally, but I still want to have the convenience of command line access and editing of my calendar since I spend nearly 100% of my time at the computer in a CLI. My hope is to get to a place where google calendar api is just one of N backends for gcalcli.

Anyway, the discussion here is good, and I appreciate the feedback and ides. I just thought I owed you guys and update on my vision for the project.

I haven't had a chance to fully review @hammerheadlemon's recent PR. Sorry for the delay!