zsh-syntax-highlighting icon indicating copy to clipboard operation
zsh-syntax-highlighting copied to clipboard

Consider converting to an `autoload`-able function

Open danielshahaf opened this issue 9 years ago • 9 comments

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 avatar Dec 20 '15 13:12 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 avatar Nov 03 '16 13:11 danielshahaf

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

danielshahaf avatar Jan 11 '17 15:01 danielshahaf

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

danielshahaf avatar Jan 29 '17 19:01 danielshahaf

Will the highlighter interface change to allow for autoloaded highlighters?

phy1729 avatar Nov 26 '17 04:11 phy1729

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

danielshahaf avatar Nov 29 '17 16:11 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 avatar Dec 25 '17 04:12 danielshahaf

Cross-referencing #688.

danielshahaf avatar Mar 16 '20 22:03 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 avatar May 22 '20 04:05 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.)

danielshahaf avatar Jun 08 '20 15:06 danielshahaf