From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22732 invoked by alias); 23 Jan 2016 23:53:07 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 37751 Received: (qmail 4995 invoked from network); 23 Jan 2016 23:53:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Date: Sat, 23 Jan 2016 23:53:03 +0000 From: Daniel Shahaf To: Zsh hackers list Subject: Re: "drop-in replacement" and transpose-words-match Message-ID: <20160123235303.GE20278@tarsus.local2> References: <160111233259.ZM6719@torch.brasslantern.com> <160118223126.ZM28565@torch.brasslantern.com> <160119195608.ZM31931@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <160119195608.ZM31931@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) Bart Schaefer wrote on Tue, Jan 19, 2016 at 19:56:08 -0800: > On Jan 19, 9:28am, Sebastian Gniazdowski wrote: > } Zsh-syntax-highlighting can be slow, which can be seen by editing ~400 > } lines function with zed -f. Maybe it's because it's doing various > } things to compensate not that rich information provided by Zsh. > > It's mostly because it's re-analyzing the entire buffer every time any > change is made, if I recall correctly from the few times I've tried it. That's basically how it works, but it doesn't explain the slowness on fned buffers: the initial highlight of an fned buffer involves exactly one _zsh_highlight call, and yet is slow. Cheers, Daniel P.S. There are two workarounds for the slowness: invoke within fned, or set the undocumented $ZSH_HIGHLIGHT_MAXLENGTH parameter.