Consider converting to an autoload-able function

[danielshahaf]

Consider converting zsh-syntax-highlighting from a sourced script to an autoloaded function. Benefits include better isolation from calling environment and zcompile byte-compliation support.

[danielshahaf]

Using autoload -U would prevent aliases in the calling environment from affecting z-sy-h. (See for example the following downstream bug report: https://bugs.debian.org/842994.)

[danielshahaf]

Note also the workers/40327 changes to autoload with an absolute path argument.

[danielshahaf]

workers/40458 mentions a useful "autoload a number of related functions" that's now possible in 5.4-to-be.

[phy1729]

Will the highlighter interface change to allow for autoloaded highlighters?

[danielshahaf]

From a mile high view, I assume that'd be an improvement.

[danielshahaf]

Once that's done we can also emulate -L and setopt warncreateglobal ${(k)zsyh_user_options[(I)warnnestedglobal} as in #413. (That construct expands to "warnnestedglobal" on zsh's that have that option and to nothing otherwise.)

[danielshahaf]

Cross-referencing #688.

[danielshahaf]

Triage: Trivial to implement (see https://github.com/okapia/zsh-viexchange/blob/339dc2d8c4d8a164c7b441d0c1e6442b0b38b3d0/zsh-viexchange.plugin.zsh#L1-L4), will help with #688 (resilience to user's setopts) and #635/#734 (loading performance): milestone 0.8.0 optimistically, but may defer this to 0.9.0 after all (e.g., if this turns out to have to be merged after redrawhook).

[danielshahaf]

milestone 0.8.0 optimistically, but may defer this to 0.9.0 after all (e.g., if this turns out to have to be merged after redrawhook).

It would be useful to merge this only after redrawhook, simply because that's the easiest way to avoid spurious conflicts in that merge. (Fixing this will involve renaming the entry point file and creating a stub in its stead; git would then conflict, rather than merge conflict-freely to the renamed file.)