Decide on a zstyle structure

[danielshahaf]

In the future we'll probably read user configurations from zstyles rather than from globals. We can do some work ahead of time by the designing the zstyle context structure now.

(To clarify: this is about the full context used for lookups with zstyle -g/-a/-s/-t, not about the context patterns used in style definitions in users' dotfiles.)

Things to possibly include in the zstyle context:

• :plugins:zsh-syntax-highlighting - namespace prefix:
• :0.5.0 - z-sy-h version number
• :${user_context} - argv[1] of the entry point; compare vcs_info foo looking up :vcs_info:foo:…
• :brackets - highlighter name
• :${$WIDGET}, :${CONTEXT} - zle state

[phy1729]

It may also be desirable to include the nesting level; so that if commands in $( ) are highlighted, they may be highlighted differently.

[phy1729]

It would be nice to have a consistent way to distinguish between a completed element and an in progress one (e.g. path and path_prefix; c.f. #148 #373).

[danielshahaf]

It would be nice to have a consistent way to distinguish between a completed element and an in progress one (e.g. path and path_prefix; c.f. #148 #373).

tldr:

#148 - special highlighting for the word currently being typed, e.g., for the command word depending on its possible completions

#373 - highlighting of unterminated string literals

[phy1729]

It may be useful to make the style reflect the nesting mentioned in #495 e.g. --"delete-${when}" the -- would be ...:option-hyphen-double, "delete- ...:option-hyphen-double:quoted-double, and ${when} ...:option-hyphen-double:quoted-double:parameter. Not sure if we should no longer overlap styles if we do that.
(Of course the particular names aren't important, just giving an example.)