From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21922 invoked by alias); 31 Mar 2017 05:53:40 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 22642 Received: (qmail 18008 invoked from network); 31 Mar 2017 05:53:40 -0000 X-Qmail-Scanner-Diagnostics: from aok120.rev.netart.pl by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(85.128.245.120):SA:0(0.0/5.0):. Processed in 3.352748 secs); 31 Mar 2017 05:53:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: psprint@zdharma.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at zdharma.org does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new using ClamAV (19) Date: Fri, 31 Mar 2017 07:53:29 +0200 From: Sebastian Gniazdowski To: Bart Schaefer , zsh-users@zsh.org Message-ID: In-Reply-To: <170330221929.ZM18456@torch.brasslantern.com> References: <170330221929.ZM18456@torch.brasslantern.com> Subject: Re: zregexparse X-Mailer: Airmail (231) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 31 marca 2017 at 07:20:56, Bart Schaefer (schaefer=40brasslantern.com)= wrote: > On Mar 29, 10:46am, Sebastian Gniazdowski wrote: > =7D > =7D I've stumbled upon zregexparse. Verified that it doesn't auto-load > =7D zsh/regex. Manual says: > =7D > =7D zregexparse > =7D This implements some internals of the =5Fregex=5Farguments function= . > =7D > =7D Test V02 suggest this is a very capable tool. How it is compiled, w= ith > =7D use of LGPL Gnu regex=3F > =20 > It has its own simple regular expression matcher, towards the end of > the zsh/zutil module. There's no borrowed code, except maybe the > algorithm from a textbook. > =20 > This was invented during the time when it had been decided that there > should be separate documentation for developers and users, so the yodl > doc was deliberately sparse on things only developers were supposed to > need to know about. Probably a poor decision in hindsight, as in many > cases the doc for developers never got written. I suspect one reason to left it undocumented is that it doesn't integrate= with syntax. Writing such functions is rather a pain from one point of v= iew, e.g. it would be easy to add Levenshtein distance function to zsh/ut= il or new module, that would match and sort according to the distance, so= that fuzzy finding fever ;) that's current would move to Zsh side, howev= er the function would be a multi-argument small hog, not (o)/(O) and no =22= =3D *glob*=22 integrated thing (however zregexparse doesn't appear to be = a hog). Coming up with some syntax for this would be a big discovery. Hmm= , I think the problem is maybe in the one feature that I'd expect: additi= onal array to be created with corresponding distances, without it it's ma= ybe even doable, the integration with syntax hmm.. In history-search-multi-word I do: =C2=A0 =C2=A0 =5F=5Fhsmw=5Fregion=5Fhighlight=5Fdata=3D( ) =C2=A0 =C2=A0 : =22=24=7Btext//(=23mi)(=24=7B=7Ecolsearch=5Fpattern=7D)/=24= (( hsmw=5Fappend(MBEGIN,MEND) ))=7D=22 =C2=A0 =C2=A0 region=5Fhighlight+=3D( =24=5F=5Fhsmw=5Fregion=5Fhighlight=5F= data ) to colorize search-query matches. Apparently zregexparse would work here = too, and who knows, maybe it would be faster. It's just about running cod= e for every match, and hopefully zregexparse has MBEGIN and MEND too. It = might be however slower, if it's written as completion-backend, nice non-= problematic code to serve completions, i.e. rather unoptimized. PS. Also = rather no array support in zregexparse, i.e. =24=7Blines=5B=40=5D//=E2=80= =A6=7D equivalent. --=C2=A0 Sebastian Gniazdowski psprint /at/ zdharma.org