Open editor when no description/annotation is passed on the command line

[joelostblom]

I would like to use my editor to write descriptions and annotations for tasks. Ideally, in a way that is similar to how git commit works, ie if I don't pass a message on the command line, vim is opened and the text written inside the vim buffer is then passed to git as the commit title + message when the editor is closed.

In taskwarrior, I would like my default editor to open if I write task add or task add project:work (ie as long as a description is not provided), and allow me to type in the task description and optionally a longer description/annotation:

I think task ID annotate without an annotation string as a command line argument, could work the same way. It is far more convenient to write long text annotations in a good editor than on the command line. Currently, both add and annotate without a description/annotation errors with the message Additional text must be provided..

I'm aware of task edit but that is a bit messy to navigate around and does not have the same ease of use as the git commit-like addition to task add/annotate that I am suggesting here. Somewhat related suggestion in #2090 but there the intent/discussion centered around report output formatting.

[djmitche]

Description and annotations both just contain strings, so in principle there's no reason they couldn't have newlines, but I suspect that would wreak havoc in terms of display. I think we want to continue to encourage not putting newlines in those fields.

Annotations are timestamped extra data on a task. I think the idea is that they form a sort of journal, or at least that's how I use them. It seems like the "long description" above would make more sense in a "notes" field or something like that.

All in all, I think if we were to open an editor, it should be similar to or identical to the task edit editor.

That said, I wonder if users would find it jarring to get an editor popping up when they don't expect it.

I'd love to have feedback from others here -- I don't have a strong sense of how or whether to do this.

[ryneeverett]

https://github.com/thehunmonkgroup/onenote

[djmitche]

Interesting! So I guess there are two questions here:

• Should we support an editor for bare task add and/or task annotate?
• Should we support a notes field a la onenote?

[ryneeverett]

I'm not sure how useful the task add editor is without a blessed long-description field, so that might be the first question to answer.

Looking at the mockup, I think it should also accept arbitrary <mods> below the description and that it should allow them to be either space or newline-delimited.

[smemsh]

Should we support an editor for bare task add and/or task annotate?

Spawning an editor using same process as "task N edit" if given no description seems reasonable. Currently it just bombs with "additional text must be provided" and I often stub it out with a '-' and add description later.

Should we support a notes field a la onenote?

FWIW, another approach, over the years, have been "tasknote" wrappers that managed external note file(s) associated with the task. There was a popular one called taskopen, apparently still developed. I personally use a simple python wrapper to edit or display an optional file in ~/.task/notes/<uuid>.rst, re-wrap my annotations as a standalone bullet list (headed by a prominent description line), or a menu to select from any urls to spawn a browser.

The "description" field currently has a role more like the first line of a git commit I think, although arbitrary string data, including newlines, should probably be allowed inside all description/annotation fields. The Taskwarrior UI doesn't need to care... external UIs are likely employed in such a case. However description could maybe have a new report format available (currently there are combined, desc, oneline, truncated, count and truncated_count), i.e. that added a line-break within the "cell" of the report, and/or one that just converted newlines to spaces.

The presence of working scripts that wrap either UDAs or annotations to allow people to edit multi-line formats may indicate that already enough machinery is present in Taskwarrior for handling these more detailed notation styles.

[joelostblom]

Thanks everyone for the comments! I ended up making a zsh function (pasted below) for the this purpose which has been working well for me over the last month. Comments on a couple of the points above:

Annotations are timestamped extra data on a task. I think the idea is that they form a sort of journal, or at least that's how I use them. It seems like the "long description" above would make more sense in a "notes" field or something like that.

I think a notes/long description field would be a welcome addition, but so far I have not encountered any issues using the annotation field with newlines for this purpose (although I haven't tested all types of reporting with it). One thing I do appreciate is that using the description.count field for reporting indicates which tasks have an annotation (i.e. long description) in brackets, e.g. Task description [1]. So if a long description field was added, having a similar field option for reporting would be useful.

Looking at the mockup, I think it should also accept arbitrary below the description and that it should allow them to be either space or newline-delimited.

I considered this but it seemed difficult to include the excellent shell completion for taskwarrior mods inside the editor. Instead, the function I made put text on the prompt after the editor is closed and modifies the just created task via the +LATEST filter tag.

---

I am including the zsh function I made below in case anyone is interested in the same functionality (the editor options are vim-specific). Since this works as desired for me and since @smemsh pointed out that there is already a fair amount of tooling to allow different types of longer notes with taskwarrior, I won't push for any additional functionality to be implemented. I think a long form notes field could be useful, but I also realize there might be more important tasks to prioritize.

function ta {
    # Opens the editor to type out the task title (description)
    # plus a potential longer elaboration (annotation)
    # Then drops into the command line to utlize tab completion for projects and tags

    # Create a temporary file
    local tmpfile=$(mktemp /tmp/my_new_task.XXXXXX)
    # Git commit syntax highlghting for differently colored title line
    ${EDITOR} -c 'set filetype=gitcommit' -c startinsert "$tmpfile"
    # Waits until editor is closed
    local title=$(head -n 1 "$tmpfile")
    local body=$(tail -n +3 "$tmpfile")
    rm -f "$tmpfile"

    if [[ -z "$title" ]]; then
      echo "No description entered. Aborting."
      return 1
    else
        task add $title
    fi
    if [ -n "$body" ] && [ "$body" != $'\n' ]; then
        task +LATEST annotate '\n'$body
    fi
    # Output text to the command prompt so that completion can be used for projects etc
    print -z -- task +LATEST modify pro:
}

[smemsh]

actually the $EDITOR spawn on empty seemed like a good idea... I was unsure about the note field, especially if the description and annotations fields already can contain newlines

[ryneeverett]

An additional implementation idea would be for the note to be a file attachment (#4038). One (weak) reason this is appealing is that notes could be stored in an arbitrary format (e.g., markdown) and the editor would automatically do the right thing (e.g. syntax highlighting) based on the extension. However, that may eliminate some of the benefits of being able to use the "long description" in reports.

I do think there is benefit to converging on a single solution for this. Personally, the thing holding me back from using any of these solutions is that I would be committing to supporting that solution on all the clients I use both in the present and the future. It's great that taskwarrior is hackable and that people can experiment with these kinds of solutions, but there is a benefit to standardization once the problem is well understood.