We'd possibly be better off popping up $EDITOR for a description (or optionally accepting it from stdin or a file) and then interpreting mail commands in that description. That feels more flexible and consistent, and probably a lot easier to use.

I don't think we should keep adding more flags. They're inflexible and we can't really make them more flexible because we can't reasonably discover them by examining server configuration since it's too slow (i.e., it's bad if you're tab-completing a command and we have to do a server round-trip to figure out what flags are available). They're also basically hard to use since you have to escape a lot of characters.

Pursuing this is a lot of work on both the client side and server side, though. We don't currently have time to help plan this out or review the changes.

That sounds like a good solution, I hadn't looked at the information on mail commands (since our installation can't get incoming mail).

For now I'll maintain the "easy fix" of adding extra flags as a local branch when I pull the latest versions.

Thanks!

The best way is to pop up $EDITOR for putting the description in. All additional stuff should be done with --browse (simply - in browser). It's "Quickly create a task for yourself." after all. At first I was surprised that arc todo did not did that, but it would be cool if arc todo would support putting description in via $EDITOR

Like T7715 (a similar task which discusses adding more capabilities to arc tasks and arc list), I don't want to move forward here by adding flags for everything. This isn't powerful and, as an example, can't accommodate custom fields without some level of generalization.

We already have a reasonable, human-facing way to write transactions using text commands in the general case: mail commands. I want to realign arc todo to use this same infrastructure. Once rewritten, the workflow would look something like this:

$ arc todo

This pops up your $EDITOR with an empty file and some comments:

>_

# Enter a task title, and optionally a description and additional commands.
# The first line will be used as a title.
# Additional lines will be used as a description.
# Use commands like "!priority high" to set properties.
# See "Email Commands: Tasks" in the web UI for a full list of commands.

You enter text like this:

Feed all of the llamas

We need to feed all of the llamas or they'll cause some llama drama.

Llamas eat wheat; don't feed the llamas meat.

!assign alincoln
!cc htaft
!priority high
!projects farm llamas

If formatted as a subject + body instead, this same text would have the same effect when sent via email.

This will give us a single, cohesive, full-power human-facing text entry UI for task creation across email, the API, and the CLI.

To get here, we need to:

• Do T5873 first, which is a large, complex, wide-reaching task that touches a large amount of infrastructure.
• Extract command interpretation so it can be invoked by both mail and API callers.
• Add an "interpret commands" flag to the new API calls T5873 creates.
• Reframe arc todo in terms of $EDITOR.

Awefricinsome!

I'm going to merge this into T11934 since I now expect to provide a more general version of arc edit <object> and make all comment areas support these commands.