if you don't specify a task, should you get a task browser ui?

[amonks]

if so, what should the task browser look like? should it list the commands and stuff or just task names? if commands, what happens for non script-task implementations of Task? should Task have a Description()string method?

also, what happens if not-a-tty? it feels wrong for tty-ness to change the behavior a lot

[ecshreve]

description field could be nice for -list output.

could be cool to have a "preview" window (a la fzf file search) that pops up the whole highlighted task

[amonks]

good point

I'm gonna split out Description into its own issue, since that seems like a quick unambiguous win whether or not there's an fzf thing

[ecshreve]

I think a task browser of some sort could be valuable.

This is a somewhat common anti-workflow I get into

• My project has a bunch of taskfiles and tasks
• can usually remember the task_id of the thing I want to do
• fairly regularly i can't recall what that task's dependencies are or the exact cmd it's going to run
• i want to take a quick look at the task before running it
• do run -list but my normal terminal pane isn't laid out vertically, so it only fits 2 or 3 tasks
• then i remember the list output doesn't have info about the cmd
• open the tasks.toml file and search the task_id
• Now I know what i wanted to, but I'm out of my terminal and in a different file than the one I was working on

A useful thing for me in this situation would a way to "preview" or "quick look" task definitions from the terminal.

---

Some ideas that came to mind:

(things that involve changing run)

• make run -list output in a table (a la docker container ls)
• add a run -short option that outputs just the task_ids and descriptions (came to mind because i was trying to pipe the run -list output into fzf and work with the tasks there)
• add to the tui a "task browser" view like the one this issue mentions, with some columns and searchability

(things that rely on outside tools, end user configuration)

• i think the pipe into fzf would work just fine but i haven't spent the time to try and parse the existing run -list output
• generate something like a "cheat sheet" file, that integrates with another terminal app (https://github.com/denisidoro/navi)

Curious if you've thought about this recently. Or if there's other tools or things y'all use with run that might make something like this easy / easier 😂

[amonks]

@ecshreve

I can definitely relate to that anti-workflow: that's me every time I come back to a project.

re: ideas,

1. Tabular output for -list is interesting. Unlike many CLIs that output tables, I think we'd need multiple lines of content in some cells, but that appears to be well supported by lipgloss's table renderer. I wonder whether it'd end up being prohibitively wide.

2. Machine-readable output would be very useful also. We don't currently have a good integration story except for with Go programs, and this could be a good fallback for integrators in other languages. Plus for scripting.

3. Personally I think an interactive browser might be the most usable option, since we could fit just-the-IDs of many tasks onto the screen, but still afford for showing details about them, just one-at-a-time. On large projects (30+ tasks) I think even a table could easily end up being too much -list output to fit on a screen, so your tasks still aren't "glanceable". I suppose this is an information design problem, so there might be a good solution, but I can't immediately picture it. Particularly since (as you note) it's often useful to see the whole cmd, which might be many lines per task.

As a bonus, if we had an interactive browser, it would take some pressure off of -list to be human-readable, and we could implement a nice parseable -list without giving up usability.

Off the dome, here are some thoughts about what a good version of that might look like:

• I think want a navigable list of tasks, some kind of search/filter, and a big panel with information about the selected task
• If it takes a very small number of interactions to get from run to running a particular task, the browser could become my default entry-point, even if I know exactly what task I want to launch. This might be a good usability north-star.
• One possibility is to make the browser look like the regular run ui, with the tasklist on the left. This is probably helpful if the browser and runner work similarly, but anti-helpful if they work differently.
• Taking that further, I wonder whether it's feasible to do this modelessly — that is, to build task browsing into the main UI rather than having two separate UIs. There are a lot of design questions here: can you launch more than one root task? When you pick a root task, what happens to the tasks in the list that aren't part of the taskset? are they in the way? is it confusing if they disappear? Maybe they're greyed out at the bottom of the list, but you can interactively launch them if you want?

[cgsdev0]

here's a little wrapper that implements a browser with fzf if you just do run with no args

i have this in my .zshrc but it should work in a .bashrc too

if which run &> /dev/null && which fzf &> /dev/null; then
  run() {
    if [[ $# -eq 0 ]]; then
      local TASK="$(command run -list \
        | grep '^  [^ ]' \
        | tr -d ' ' \
        | fzf -0 --ansi)"
      command run "$TASK"
    else
      command run "$@"
    fi
  }
fi

[amonks]

Related: once we have a UI for browsing tasks and inspecting their dependencies and configuration, we could also offer it in regular task-running mode. "hit i to show task info" kind of thing. I'll make another ticket and link it here.

[amonks]

#128