Completion only works as first argument

[bitozoid]

If I understand it correctly, --complete should be the last argument for tome completion to work. However, it seems to ignore the rest of the arguments.

I created a sample script (see below) to test completion, it seems not to work as expected.

To test:

• create a test directory

[ -d /tmp/tome-test ] || mkdir /tmp/tome-test

• copy script contents to /tmp/tome-test/testcomp.

• prepare the script and tome

chmod +x /tmp/tome-test/testcomp
eval "$(tome init test /tmp/tome-test bash)"

• Check that the script works as expected:

/tmp/tome-test/testcomp --complete
# -m
/tmp/tome-test/testcomp -m --complete
# hello
# hi
# foo
/tmp/tome-test/testcomp -m h --complete
# hello
# hi

• Try tome completion: always returns -m.

Sample script testcomp:

#!/bin/bash
# COMPLETE

sample_modes="hello hi foo"

complete_modes() {
  local modearg="${1:-}"
  if [ -z "$modearg" ]; then
    echo "$sample_modes" | sed 's/ /\n/g'
  else
    compgen -W "$sample_modes" -- "$modearg"
  fi
  exit 0
}

parse_args() {
  local opt last_opt last_opt_arg

  if [ "$1" = "--complete" ]; then
    echo "-m"
    exit 0
  fi

  while [ "${!OPTIND:-}" != "--complete" ] &&
    getopts "m:" opt; do
    case $opt in
    m)
      mode="$OPTARG"
      [ "$mode" = "--complete" ] && complete_modes ""
      ;;
    esac
    last_opt="$opt"
    # last_opt_arg="$OPTARG"
  done
  shift $((OPTIND - 1))

  # assume all arguments already processed at this point
  if [ "$1" = "--complete" ]; then
    if [ "$#" -gt 1 ]; then
      echo "ERROR: '--complete' must be the last argument."
      exit 1
    fi
    case $last_opt in
    m)
      complete_modes "$mode"
      ;;
    ?)
      exit 1
      ;;
    esac
  fi
}

parse_args "$@"

case "$mode" in
hello)
  echo "Hello World!"
  ;;
hi)
  echo "Hi World!"
  ;;
foo)
  echo "foo bar"
  ;;
*)
  echo "unknown mode: $mode"
  exit 1
  ;;
esac

[bitozoid]

I forgot to mention that I'm using tome version 0.11.1. I see no change in the completion behavior in 0.12.x changelogs. Besides, there is no linux/glibc/amd64 binary published yet.

[toumorokoshi]

I forgot to mention that I'm using tome version 0.11.1. I see no change in the completion behavior in 0.12.x changelogs. Besides, there is no linux/glibc/amd64 binary published yet.

I'll took a look at the main issue now, but FYI the binaries were released for 0.12.2: https://github.com/toumorokoshi/tome/releases/tag/v0.12.2. I hope that helps on that front.

[toumorokoshi]

Can you elaborate with the shell you are using? depending zsh and bash, there are two different paths for setting arguments and completing them: https://github.com/toumorokoshi/tome/blob/main/src/commands/init.rs#L55

On bash I do see that we're not using the full list of arguments, so that may indeed the be reason:

function _{function_name}_completions {{
    export {script_root_environment_variable}="{script_root}"
    local token_to_complete tome_args
    token_to_complete="${{COMP_WORDS[COMP_CWORD]}}";
    tome_args="${{COMP_WORDS[@]:1}}";  # strip the first argument prefix, which is the function name
    # strip the partial token_to_complete, if there is one
    tome_args="${{tome_args%$token_to_complete}}";
    all_options=`{tome_executable} command-complete {script_root} -s {shell} -- $tome_args`
    valid_options=$(compgen -W "$all_options" -- "$token_to_complete")
    COMPREPLY=($valid_options)
}}

(likely we need to use some amount of "$@" here).

[toumorokoshi]

So that was a red herring - it's actually because the args are added at the end, not at the beginning before --complete:

https://github.com/toumorokoshi/tome/blob/main/src/script.rs#L157-L158

So with that - I'm wondering if it's better to just update the documentation rather than the behavior?

I'm also wondering if just having an explicit subcommand, such as complete (e.g. complete -m would be more ergonomic? Its a minor difference but would allow for completion subcommands to be written rather than having to check a flag.

[bitozoid]

As far as I see, there seems not to be any binaries for glibc, only for musl.

[bitozoid]

Sorry about the slop. Next is claude generated answer and it makes sense to me. Hence, I would just update the documentation.

Whether to use a flag or a subcommand I don't get how the subcommand would be implemented. Then, the parent comand would have to be a directory, wouldn't it?

---

Question: Would --complete be the first argument or the last argument?

Answer: follows.

First argument — and that's not just convention, it's close to a hard requirement given how getopts works.

Why first

Your normal invocation is:

myshell --complete <the rest of the command line being completed>

If --complete came last, you'd have a problem: getopts stops consuming options as soon as it hits the first non-option token (or you'd need + mode / manual reordering to get around that). Since the "rest of the command line" being completed is itself a mix of flags and positional args for the target subcommand, you can't reliably scan past all of that to find a trailing --complete — you'd have to fully parse the tail first to even know where it ends, which is circular.

Putting it first turns completion dispatch into a trivial pre-check before your real getopts loop even starts:

if [[ "$1" == "--complete" ]]; then
  shift
  # "$@" is now the exact words being completed, in order
  do_completion "$@"
  exit 0
fi

# normal getopts parsing continues here for regular invocation
while getopts "..." opt; do
  ...
done

This is exactly the shape Cobra's __complete takes too — it's always the leading token: mytool __complete sub --fla, never trailing. Same idea, different spelling.

The other reason first is better: $CURRENT/$words alignment

From zsh, you're passing along ${words[@]} more or less verbatim after your sentinel:

completions=("${(@f)$(myshell --complete "${words[@]}" --cword=$CURRENT)}")

If --complete is first, $2, $3, ... map cleanly onto words[1], words[2], ... (the actual command being typed), with no ambiguity about where "your" flag ends and "their" tokens begin. If it were last, you'd need a separator (like --) anyway to avoid it being swallowed as one of the completion words — at which point you've just reinvented "put a fixed sentinel at a fixed position," except now it's the end for no benefit.

So: --complete first, sentinel-style, then the raw words being completed as the remaining argv. That's the pattern to keep.

[bitozoid]

Btw, I have managed to make completion work using bash and --complete as the first argument with 0.11.1 and the current implementation.