Re: zregexparse

[Sebastian Gniazdowski <psprint@xxxxxxxxxxx>]

On 31 marca 2017 at 07:20:56, Bart Schaefer (schaefer@xxxxxxxxxxxxxxxx) wrote:
> On Mar 29, 10:46am, Sebastian Gniazdowski wrote:
> }
> } I've stumbled upon zregexparse. Verified that it doesn't auto-load
> } zsh/regex. Manual says:
> }
> } zregexparse
> } This implements some internals of the _regex_arguments function.
> }
> } Test V02 suggest this is a very capable tool. How it is compiled, with
> } use of LGPL Gnu regex?
>  
> 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.
>  
> 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 view, e.g. it would be easy to add Levenshtein distance function to zsh/util 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, however the function would be a multi-argument small hog, not (o)/(O) and no "= *glob*" 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: additional array to be created with corresponding distances, without it it's maybe even doable, the integration with syntax hmm..

In history-search-multi-word I do:

    __hsmw_region_highlight_data=( )
    : "${text//(#mi)(${~colsearch_pattern})/$(( hsmw_append(MBEGIN,MEND) ))}"
    region_highlight+=( $__hsmw_region_highlight_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 code 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. ${lines[@]//…} equivalent.

-- 
Sebastian Gniazdowski
psprint /at/ zdharma.org