Skip to content
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

Fixes to keep up with gcalcli #407

Closed
youngmoney opened this issue Apr 25, 2016 · 12 comments · Fixed by #438
Closed

Fixes to keep up with gcalcli #407

youngmoney opened this issue Apr 25, 2016 · 12 comments · Fixed by #438
Assignees

Comments

@youngmoney
Copy link
Contributor

Hi, I am in the process of switching from gcalcli to khal (since vdirsyncer now supports google). I have noticed that in terms of commands gcalcli seems to be ahead in a few ways. I would like to help bridge that gap.

A few ideas (in order of priority for me):

allow agenda to have different formats (#273) including json (and for me TSV), or at the very least a pretty default, the setup I have looks like:
screen shot 2016-04-25 at 9 26 56 am
this setup was created using awk piped from gcalcli tsv output, and recreated using some regex from khal agenda output

an upcoming command, in gcalcli this calls an external command with event that will start in the next N minutes, all I care about is having either at or agenda support a next N minutes start and then a reasonable output format so that I can parse for notifications

interactive new and edit/delete, these commands would either drop right into the new/edit or interactive or have their own flow, the point here would be to initiate from the command line. In gcalcli one can type gcalcli edit SEARCH which will loop through all matches and ask what you want to do (same with delete). We could easily have a loop over matching searches and ask if edit or delete is waste and or use a similar edit flow and the interactive new. The point is that some people (myself) do not want to open ikhal, then search, then edit, when a simple khal edit SEARCH would find the event and allow me to change one detail. (shot below)
screen shot 2016-04-25 at 9 35 50 am

As I am new to the project I am really just trying to gauge whether these changes are within what khal is trying to be. Please let me know any thoughts, I will hopefully start on this in the next few weeks.

@untitaker
Copy link
Member

untitaker commented Apr 25, 2016

  1. This is bikeshedding, and I have no opinion. It's @geier's call. If we change it, it would need to be consistent with the right column of ikhal, and the agenda column of khal calendar.
  2. This is nice. I wonder if khal agenda and khal at could be merged into one command.
  3. I would prefer that workflow too.

@geier
Copy link
Member

geier commented Apr 25, 2016

Welcome @youngmoney and thank you for your interest in improving khal and especially the effort you already took with supplying those images.

A lot of good ideas here. Here's my take on them:

  1. I have no problem with a --json flag (or --tsv for that matter). I would actually like to make printing of events completely customizable, e.g. like strftime() or .format() does it (I thought we had an issue for that, but if we do, I cannot find it).
  2. I also really would like to merge agenda and at, see How should at and agenda work? #273. Something like upcoming, combined with --json would probably be a good starting point for anyone interested in implementing Alarm user on alarm #148
  3. Sounds good, probably somewhat similar to delete events from khal #49.

@youngmoney
Copy link
Contributor Author

youngmoney commented Apr 25, 2016

(sorry about the edits github was showing things poorly)

I would like to propose the following for me to start working on soon:

  1. a format string supplied in the command line via --format ""
    overriding the option that can also be supplied in the config file. In
    the config I would like to have to options: agendaformat and
    agendaformatshort. Agenda format short defaults to agendaformat and
    agendaformatshort would be used in the ikhal and right side of the
    calendar, as this would have lease width real estate.

The format string would be strftime like, I would like to keep
everything one character to it is easier to parse in a loop. Something
like: khal agenda --format "%D %s-%e %t %l %i" would show the day of
the event for the first occurance of the day but nothing after, the
start time, -, the end time, the title, the location, the description.

I would like to do something with padding there too so things can look
pretty, and also colors would be nice, but I'm not sure what syntax to
use there.

for 2. I will wait on this as it seems things are moving foreward on agenda
being something else. All I really want to see is a start on stop
datetime option/ability. That would allow for full control over agenda
down to the second (if that is part of ones datetime settings). This
would also fix a few other problems people seem to have about seeing or
hiding events (eg those that are done). If no one else does, I can work
on this after 1.

and 3. I think #49 and #179 could come together on this, being able to
launch the editor/have different editors would/could be necessary for
this to work, I can look into this after 2.

@geier
Copy link
Member

geier commented Apr 25, 2016

@youngmoney I think you misunderstood me, nobody is working on 2., I just would like to see it happen.

BTW if IRC is your thing, come join us at #pimutils @freenode

@youngmoney
Copy link
Contributor Author

ahh I see well the I propose that I bundle that with 1 and do an enchantment of agenda, preferably I'd like to change the syntax to khal agenda start [end] where start and optional end can be either date, date time, or time (if just time the date defaults to today. Also the the string 'now' or the string 'today' for date time and time respectfully.

@youngmoney
Copy link
Contributor Author

As a side note, what is the recommended development setup, I don't see anything about this, as I haven't done much with package organized python I'm not sure what to do other than make edits and then install them using python3 setup.py install, but this seems like overkill

@untitaker
Copy link
Member

Use virtualenv: http://virtualenv.readthedocs.org/

Inside that virtualenv, do pip install -e . (equivalent of python setup.py develop).

Then you can edit khal sourcecode and don't have to reinstall to see the
effects.

On Mon, Apr 25, 2016 at 01:57:13PM -0700, Youngmoney wrote:

As a side note, what is the recommended development setup, I don't see anything about this, as I haven't done much with package organized python I'm not sure what to do other than make edits and then install them using python3 setup.py install, but this seems like overkill


You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#407 (comment)

@geier
Copy link
Member

geier commented Apr 25, 2016

It's probably a good idea to just have agenda (or whatever new name) just behave as at does now when only START is given and like agenda when an START and END are given and handle dates like START + END.

Also, perhaps we could use the .format() language, in that case the user can do alignment on their own, I don't know if it's dangerous do just take any user input and do a .format() on it.

@youngmoney
Copy link
Contributor Author

just an update for where I am, I am used .format() which is working beautifully

of course some of my styling is not exactly "on brand" yet (eg there are arrows going into arrows). I will update that soon. As a side note the lt function for events assumed they were on the same day, I have updated that, and in addition I would like to add a new object DateRange that will represent a start and stop range, I have found that many of my functions use the same prologue for accepting dates and similar if blocks, so I am going to put all of that into an object.

Let me know what your thought are on these changes, as well as the new command list

As an example the command (spaced to be more readable):

khal list --format "
{yellow}{start-date-once:<12}{reset}
 {blue}{start-end-time-style:<16}{reset}
 {magenta}{title:<.50}{reset}
 {recurse}
 {cyan}{location:<.25}{reset}"
"2016-4-25" "2016-4-30"

outputs:

screen shot 2016-04-26 at 6 38 08 pm

@geier
Copy link
Member

geier commented Apr 27, 2016

nice! The arrows might prove painful to get aligned right, because of issues with single and double width characters, related to either locale or fonts. Perhaps they'll need to be replaced (though I'd be sorry to see them go, I do like these unicode symbols).

Feel free to send PRs for small issues like better sorting as well or just some WorkInProgress PRs on your whole branch.

@youngmoney
Copy link
Contributor Author

I would now like to start working on getting the new command to be interactive. I am trying to do it now using a wrapper, but I don't think this will feel as good as actually doing it inside the controller. That is I won't be able to check values as the script progresses. Also, new has some very specific style choices about its input that I'm not sure I can just drop a wrapper around. So the question becomes: Should I create a new interactive new command (not my first choice). or should I rebuild parts of new to make interactive use more viable.

The way I ideally wanted this to work is that you call new with all optional arguments, if you do NOT pass -i or --interactive then the normal new runs (and fails if you are missing important arguments). Otherwise if you want it interactive then the interactive wrapper or preprocessor or whatever it will be takes over and prompts the user for all of the missing information (and maybe for the information provided as well, using the passed info as defaults). I would like to have an option for calendars where ? could be passed in and the list of calendars would print and then the option to pick a calendar would appear again. In addition I would like the end date to support time deltas and otherwise be the same semantics as list.

As a separate note after this I also want to create interactive versions of edit and delete, these two would be built on top of search so I will be digging into search as well.

@geier
Copy link
Member

geier commented May 25, 2016

While I'm not sure how exactly you envision such an interactive mode, feel free to refactor new to support that. Datetime support for new would be great as well.

Am 25. Mai 2016 02:22:30 MESZ, schrieb youngmoney notifications@github.com:

I would now like to start working on getting the new command to be
interactive. I am trying to do it now using a wrapper, but I don't
think this will feel as good as actually doing it inside the
controller. That is I won't be able to check values as the script
progresses. Also, new has some very specific style choices about its
input that I'm not sure I can just drop a wrapper around. So the
question becomes: Should I create a new interactive new command (not my
first choice). or should I rebuild parts of new to make interactive use
more viable.

The way I ideally wanted this to work is that you call new with all
optional arguments, if you do NOT pass -i or --interactive then the
normal new runs (and fails if you are missing important arguments).
Otherwise if you want it interactive then the interactive wrapper or
preprocessor or whatever it will be takes over and prompts the user for
all of the missing information (and maybe for the information provided
as well, using the passed info as defaults). I would like to have an
option for calendars where ? could be passed in and the list of
calendars would print and then the option to pick a calendar would
appear again. In addition I would like the end date to support time
deltas and otherwise be the same semantics as list.

As a separate note after this I also want to create interactive
versions of edit and delete, these two would be built on top of search
so I will be digging into search as well.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#407 (comment)

Sent from my phone. Please excuse my brevity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants