search

zsh-users / zsh-syntax-highlighting

Fish shell like syntax highlighting for Zsh.
github.com/zsh-users/zsh-syntax-highlighting
BSD 3-Clause "New" or "Revised" License
20.16k stars 1.33k forks source link

Consider converting to an `autoload`-able function #252

Open danielshahaf opened 8 years ago

danielshahaf commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

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

danielshahaf commented 7 years ago

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

phy1729 commented 6 years ago

Will the highlighter interface change to allow for autoloaded highlighters?

danielshahaf commented 6 years ago

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

danielshahaf commented 6 years ago

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 commented 4 years ago

Cross-referencing #688.

danielshahaf commented 4 years ago

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 commented 4 years ago

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.)