Re: zregexparse

[Sebastian Gniazdowski <psprint@zdharma.org>]

On 31 march 2017 at 23:15:31, Bart Schaefer (schaefer@brasslantern.com) wrote:
> } 1, 1, 1, 1, a
> } 3, 3, 1, 2, bc
>  
> The return values from zregexparse are pretty strongly tailored to be
> used with compset and compadd, and it does nothing useful with $match
> and friends -- it's not tied into glob pattern referencing at all.
>  
> The values stored in $p1 and $p2 here are intended to calculate offsets
> into "abc" for a call to compset -p, which isn't going to help you with
> ranges for highlighting. Also (though not significant in this eample),
> zregexparse expects words joined with $'\0'.

Let me just express regret about this outcome. Redundancy is a cool thing. I was able to filter $history with (M)/:# and (R), and (R) turned out to be faster. zregexparse could prove its value in e.g. static build without zsh/regex. One IRC user once reported problems with some completions, because he sincerely configured BSD port as static build (no zsh/regex by default). I then quickly removed regex usage from _hosts, but the patch wasn't accepted, maybe because the problem wasn't highlighted (that said, I may naively equate zsh/regex with zregexparse, but it's just that shipping own regex engine is extreamly cool, at least for me). I once wrote simple ANSI color codes parsing using (#b), wonder if here the zregexparse could do something, but it would have to be able to progress across text, and lack of mend seems to be a problem.

-- 
Sebastian Gniazdowski
psprint /at/ zdharma.org