Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CAH+w=7b7g-g7JmFvrgR4ezWz7CrVZnXVrV+u9iOitX0H0y_pVQ@mail.gmail.com>
References: <CAKc7PVCZhyjPqzgPSrKOUs=+Qp5m_yELs2uEAwuCQYZXDKkxUg@mail.gmail.com>
 <CAH+w=7b7g-g7JmFvrgR4ezWz7CrVZnXVrV+u9iOitX0H0y_pVQ@mail.gmail.com>
From: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Date: Sun, 15 May 2016 17:24:00 +0200
Message-ID: <CAKc7PVDQ-1Kh7EngkJSmB7buk0bEAkwsgZZVhLWW-fMaqnsdKw@mail.gmail.com>
Subject: Re: How can Zle -U interfere with zsh-syntax-highlighting?
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Content-Type: text/plain; charset=UTF-8

On 15 May 2016 at 13:13, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> Is there some alternative to Zle -U?
>
> Other than just LBUFFER+="long text here", no.  If you want the other
> effects of zle -U (i.e., that each character is interpreted as if it
> had been typed) then there is no alternative.

Forgot about LBUFFER, thanks! I have two tools, and it is interesting
that in one (n-history) doing LBUFFER+="$var_with_long_text" causes
highlighting to correctly work (and also solves the lag issue) whie in
other tool (n-kill) it doesn't trigger highlighting. I made the two
responsible code blocks identical (I do zle redisplay and zle
kill-buffer before zle -U / LBUFFER+=), even hardcoded the text:

LBUFFER+='a=; a=${(r:100000::_:)a}...'

and it still behaves this way. Both tools use emulate -L zsh, also
tried emulate -LR zsh. Luckily, I need LBUFFER+= only in the one tool
that works.

Best regards,
Sebastian Gniazdowski