-
Notifications
You must be signed in to change notification settings - Fork 200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use more convenient dates and times #169
Comments
This is a good idea and I've thought about this myself. The problem with using GNU date is, that while it my be legal to import GPL licensed code I'm not sure its not against the wishes of the author. So I would prefer a MIT/BSD etc. licensed package to be used. An apache licensed module for which could be helpful is parsedatetime. For the where, have a look at If you have any more questions, don't hesitate to ask. I'd love to see a pull request for this. |
I'd consider using GNU tools a valid option re legal situation, but doing so might harm portability. |
You might also want to do this the way GNOME California does: Just take a description, and extract the dt from there if found. We should also add CLI options for enforcing the date with strict behavior (for scripts invoking khal new), and make the user use that if we fail to extract a date. |
California's quick add looks pretty nice, lots of good ideas waiting to be stolen |
The parsedatetime module looks good, california seems even better but their code is unusable here (looks like it's written in Vala and GPL licenced). For the where, did you mean |
@bcudini yes, I did mean |
I just had a look at california's details parser. While it is obviously a lot better than what we currently have, their approach is at least similar: Tokenize the input string and then use different parsers for different components (start, end, duration, location etc) on that stack, popping elements if they are 'used'. |
If you want to help with this issue, just write down all variants you can think of a clever quick add function should understand. |
AFAIK, California's implementation was rather broken in that it expected US-formated date (eg: "Monday 6pm") and did not work with standard time formats ("Monday 1800hs", "Monday 1800", etc), as well as some other really common variations.. However, the high level idea should work.
Possible formats for input:
Recurring events sound a bit trickier, but are basically determined by the way
Non-infinite recurring events:
Ironically, I don't drink as much beer as you'd expect, they were just the quickest examples. 😄 |
To anyone who wants to start working on this, I would recommend having a look at spacy (which has just been relicensed under MIT license), to me it looks like the most practical solution for natural language processing (I only did some quick experiments with it though). |
another interesting looking library (haven't tried it yet): https://github.com/akoumjian/datefinder |
[ref] |
@hobarrera alright, that doesn't look like it fits our use case. |
|
I'd like to have a way to add new events more conveniently. For exemple:
khal new thursday drink beer
khal new '2 months' laundry
In fact, using GNU date from command line, you can use all kind of dates format, like the ones I explained. I was thinking about using the same in khal, and I would do that myself but don't know where the dates and times are parsed in khal's code. Any pointer would be appreciated, so that I can do it and offer a patch
Thanks
The text was updated successfully, but these errors were encountered: