[misc] Request For Comment: better command line modification and output

Dear list,

Lukas mentionned before that having a better command line interface
might be a good things for testing. I am actually interested in
contributing to that to provide an android interface to calcurse(more
details on that in a later post), but I am not sure what should be the
interface for it. The intent of this mail is to present how I see the
interface so as to obtain a feedback on details I might have missed,
useful features I haven't though about, and on the interface itself.

The first feature I would like to add is a --delete-todo <regexp>
option. A regular expression is passed as an argument to the
option. All the todos that match exactly the regular expression are
removed. Requiring an exact match should avoid data loss compared to
partial match. Of course, "--delete-todo .*" remains dangerous. 

If you believe it is necessary we can imp improve the security of the
operation further. For instance by making multiple options
--delete-todo-allmatch, --delete-todo-first, --delete-todo-single to
remove all the matches, the first match or only one match (and return
an error if there is more than one). An other way would be not to use
regexp but only perfect string match.

For simplicity, --delete-todo is exclusive with any other option
(beside -c and -D).

The second feature I would like to add is a --add-todo <text>
option. But here, I am not sure of the interface. There are
potentially three important parameters. The text of the todo, the
priority of the todo, and potentially the notes that goes with the
todo. The text of the todo could be passed as a parameter to the
--add-todo option. The note could be read from standard input if a
--with-note option is specified (or maybe copied from a file and take
standard input if the filename is "-"). The priority could be given
through a mandatory option --with-priority <priority>. Or we could
make the --with-priority not mandatory and take a default value of 5
for the priority.

The third and fourth features I would like to see are the equivalent
of the first two ones for appointment. But here it becomes more

To delete an appointment, we need to identify it uniquely. A regular
expression used on the text of the appointment won't be enough. We
most likely need to specify the date in some fashion (or we risk
severe data loss). I guess we could use the -d, -r, -n options to
specify the date. So I guess a --delete-appointment <regexp> option
would do. It looks inside the current day by default or within the
days specified by -d, -r or -n. What about recurrent appointments?
should we need to make the distinction with all-day events?

Adding an appointment is no easy task as well. We need to input start
day, start time and end time. I guess we could make a parameter out of
all of that. We could use a --add-appointment <text> options. We could
use the same convention to specify a note file that the one used for
todos. The day would be given by a --on-day <date>. We could use a
parameterless --all-day parameter for all-day event. Otherwise, a
--start-time <time> parameter would give the start time and a
--duration <duration> or a --end-time <time> would specify the end

Processing recurrent appointment might be a problem. Should we have
different option names for them ?

The last feature I am interested in is user defined command line
display. What I mean is allowing the user to choose the format of the
output when using -t and -d to specify the format of appointment,
todos, and their order. An exemple use case would be:

$ calcurse -t --todo-format-global "My %n todos:\n%T" --todo-format-ind "%p)%t (%n)\n"
My 2 todos:
1)conquer the world (no note file)
2)brush your teeth (3 minutes at least and don't forget to call the doctor)

In the format-global, a %T would list the todo from higher priority to
lower priority, a %t would do the reverse. Similar features for
appointment can be designed that would allow to display time in AM/PM
format or in military time format. You could access the start time
(with %s and %S), end time (with %e and %E) and duration (in minutes
with %d or in the hh:mm with %D). Since there are so many format, we
could do %d(HH:MM) to express the duration should be given in HH:MM
format or %d(mm) totally in minutes.

That feature would allow easier export data to non calcurse format and
to expose them in easier to parse format for external tools.

Any comment would be welcome. Once we agree on an interface, I will
probably start with the todo features which I expect to be easier.

L'analyse se fait par cas, comme la veste.[Erik2008]