sudo long flags not recognised

[baltitenger]

Long flags for sudo (e.g. --askpass or --preserve-env) are treated as commands, and highlighted for not existing. The plugin also seems to assume sudo [flags] [env] [command] [args...] order, but flags and env can be mixed. (e.g. in sudo -s foo=bar baz, it recogdies -s as a flag, foo=bar as an environment variable, and baz as a command. but in sudo foo=bar -s baz, foo=bar is recognised as env, -s as a command, and baz as an argument)

[danielshahaf]

This is a multi-pronged issue; let me break it down.

Long flags for sudo (e.g. --askpass or --preserve-env) are treated as commands, and highlighted for not existing.

• 641.1 --foo flags that don't take an arguments: Easy.
• 641.2 --foo=bar flags that take an argument in the same word: Easy.
• 641.3 --foo bar flags that take an argument in the next word: Would require hardcoding the list of such options, as we already do for one-letter options.
  Status: not urgent, since there's a workaround: using the --foo=bar syntax.
• 641.4 -- end-of-options marker: Easy.
  Status: That's main: Do not highlight options after -- #502

The plugin also seems to assume sudo [flags] [env] [command] [args...] order, but flags and env can be mixed.

(e.g. in sudo -s foo=bar baz, it recogdies -s as a flag, foo=bar as an environment variable, and baz as a command.

This is a bug. The assignment is highlighted here for the same reason it's highlighted in % LC_ALL=C ls, but the code is generic and most precommands don't allow assignments here; sudo and env are exceptions. So:

• 641.5 nice x=y ls: Should be unknown-token. Easy to support with a little state machine work.
• 641.6 sudo -s foo=bar ls, env x=y ls: Currently work. Are exceptions to the case in the previous bullet.

but in sudo foo=bar -s baz, foo=bar is recognised as env, -s as a command, and baz as an argument)

• 641.7 sudo foo=bar -s ls: Could be supported, but it's unique to sudo.

[danielshahaf]

Tentatively setting milestone to 0.8.0, but it's not a release blocker.

[danielshahaf]

#658 proposes changing the behaviour so the flags would be highlighted as ordinary double-quoted options (default: no highlighting) rather than an error. (Yes, I should perhaps have thought of that sooner.)

[danielshahaf]

Changing the error highlighting to no highlighting (as it was in 0.6.0) is tracked under #658/#664 and is milestoned for 0.7.0. The remainder is new features and not particularly urgent so I'm unscheduling them. (Would be nice to hook into the completion system and solve the long options support this way...)