[willyg302]

> complex parseable options, something that could only be parsed by a parser generator

Could you elaborate on this? Do you mean user input more like natural language? I've seen a few attempts at this such as betty [1], but the reality of it is the input must still be translated into something the CLI understands, and as you might imagine it becomes difficult for more obscure options.

1. https://github.com/pickhardt/betty

[fiatjaf]

Are you just parsing the text and covering all those options? Or are you doing some sort of natural language processing?

I didn't meant something so abrangent, I meant something simpler. For example, `ls`:

Instead of `ls -l`, `ls complete` or `ls with metadata`.

Instead of `ls -L`, `ls following symlinks`.

Instead of `ls -a`, `ls all` or `ls with all`.

I don't remember exactly what I was thinking.

[willyg302]

I like this idea, but no, clip is about as simple as you can get. Direct greedy parsing one token at a time.

It seems like you could get something like your examples by doing option aliases, so typing "complete" or "metadata" would be parsed as `-l`. However even something this simple starts to complicate parsing quite a bit (e.g. where are the option boundaries?) especially if you allow multiple tokens in an alias, like "with all" --> `-a`.

And at the end of the day, it just helps to learn through repetition. I have no idea what the "plant" means in `netstat -plant`, but I know it generates the output I want. Similarly it's much easier to type `ls -latr` than "ls complete all sort oldest first".