Daniel Shahaf

> In INSTALL.md, shall we change `source ./zsh-syntax-highlighting/zsh-syntax-highlighting.zsh` to `emulate zsh -c "source ./zsh-syntax-highlighting/zsh-syntax-highlighting.zsh"`? Actually, it might be easier to add a layer of indirection: ```zsh % git rename zsh-syntax-highlighting.zsh...

Triage: Deferring until after redrawhook is merged to prevent annoying merge conflicts upon that merge.

> Triage: Deferring until after redrawhook is merged to prevent annoying merge conflicts upon that merge. Triage: Unblocked; milestoning 0.8.0, but will defer it if that release is ready before...

Compare #705, which is also about continuation lines. There's a zsh patch attached to #705. With that patch, however, multicharacter tokens with a backslash-newline partway through wouldn't be recognized. Therefore,...

> would work, but that's just special casing `$var/string` when many > different characters can end a variable name. It wouldn't be hard to rewrite it to support «$var.string», «$var,string»,...

Opened #485.

$AUTOINCREMENT was a made-up example. Let's ask upstream's opinion.

Posted [users/23095](http://www.zsh.org/cgi-bin/mla/redirect?USERNUMBER=23095). While writing that I realised that evaluating only if `${parameters[$foo]} != *special*` would probably be safe (but let's see what the thread results in).

Assigning this back to the pool: the $AUTOINCREMENT issue was handled by #489.

Issue sweep: two separate concerns here: 1. Don't make the command word red when we don't know whether or not it'll execute successfully or not. 2. Support `${foo}/bar` in command...