Completion Chat November 2019

Back to Shell Autocompletion

Notes from discussion:

• ls | grep and ls | wc -l make sense because the second commands read from stdin, but ls | ls doesn't. But none of bash/zsh/fish understand that.

API

I think it can be as simple as an API to throw exceptions for command errors, e.g. consider:

grep --no-filename
grep --max-count
grep --max-count=

These all result in syntax errors, and some of them are different. Right now most commands aren't consistent about how they report errors.

But the "carrot" is if they are consistent and use an Oil API, then they will completion for free, and it will be correct.

---

Of course you also need to display completions when there are no syntax errors, like

grep pattern file1.c <TAB>

should complete another file, even though the prefix is a valid command

only the command knows

1. if an flag takes an argument
2. If so, what kind of argument it is

So the syntax error can include a completion type, like

raise SyntaxError('FILE', 'file expected')
raise SyntaxError('HOST', 'host expected')

raise SyntaxError('arg expected')  # a command arg, not flag arg

You could implement such a parser/API in any language but I would start with Oil. I guess you could do it in sh with global variables since it doesn't have rich return values/exceptions.

That is another instance of the problem where the sh language isn't expressive enough to express basic things about its problem domain.

---

• the success case is a problem, you might have to force the user to return a "completion hint" as well as parsed options, e.g.

def Parse(argv):
  # maybe raise syntax error
  return opts, CompletionHint('FILE')  # success, but could be more args