Feature request: #a (approximate matching) only for spaces

Feature request: #a (approximate matching) only for spaces

[Sebastian Gniazdowski]

Hello,
currently #a{num} works on any character. It would be useful to have
it work only on spaces. For example, if someone greps history with
"gitpush", it would match "git push". Current #a does this match like
described, however it also adds "noise" by doing matches with all
other errors handled by #a, for all characters.

Also, I wonder if there can something be done to handle searches as follows:

gitpurge
#=> git remote purge origin

Best regards,
Sebastian Gniazdowski

Re: Feature request: #a (approximate matching) only for spaces

[Mikael Magnusson]

On Sat, Dec 5, 2015 at 9:43 AM, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> Hello,
[...]
> Also, I wonder if there can something be done to handle searches as follows:
>
> gitpurge
> #=> git remote purge origin

% touch git\ {remote,foo,bar}\ {purge,baz,bing}\ {origin,upstream}
% s=gitpurge
% print -l ${~s//(#b)(?)/$match[1]*} # make the pattern g*i*t*p*u*r*g*e*
git bar purge origin
git bar purge upstream
git foo purge origin
git foo purge upstream
git remote purge origin
git remote purge upstream

-- 
Mikael Magnusson

Re: Feature request: #a (approximate matching) only for spaces

[Bart Schaefer]

On Dec 7,  5:44am, Mikael Magnusson wrote:
}
} % print -l ${~s//(#b)(?)/$match[1]*} # make the pattern g*i*t*p*u*r*g*e*

Yeah, but that also matches gfooifootfooifoopfooufoorfoogfooefoo, which
I'm not sure is what Sebastian wants.  The pattern

(g*tpurge|gi*tpurge|git*purge|gitp*urge|gitpu*rge|gitpur*ge|gitpurg*e)*

is probably closer to what he wants, but it's a bit ugly to generate a
pattern like that:

    setopt histsubstpattern extendedglob
    s="gitpurge"			# string is $#s chars long
    a=( ( "${(@)${(s::)s}/?/}" )	# array of $#s empty elements
    x=( ${s:^^a} )			# array of $#s copies of $s
    i=1
    p=( ${x:s/(#b)(#s)(?(#c$[i++]))/$match[1]*} )	# $#s patterns
    print -lr - (${(j:|:)~p})*		# join and enable matching

Amazingly, you can write that as a one-liner, if you don't count the
necessity of the setopts and declaring the parameters:

    (${(j:|:)~${i::=1}+${${:-$INPUT"${(@)^${(s::)INPUT}/?/}"}:s/(#b)(#s)(?(#c$[i++]))/$match[1]*}})*

I renamed $s to $INPUT to make it easier to pick out from the rest of
the chicken scratching.

Breaking that down ...

    1. ${i::=1} forces $i to reset to 1 before the rest of this expands.
    2. The "+" after that says that if $i is set, substitute what follows
       instead.  Since we just forced $i to be set, this always happens.
    3. ${:-words} inserts those words as a nested expansion where they
       otherwise would be a parse error.
    4. "${(@)^${(s::)INPUT}/?/}" forms an array of $#INPUT empty elements
       and also turns on rc_expand_param [the caret after (@)].
    5. Juxtaposing (4) with $INPUT results in $#INPUT copies of $INPUT
       as an array for the rest of the substitution to act upon.
    6. The :s// expression applies to that array such that $[i++] is
       evaluated for each element.  This is unlike ${..//pat/rep} which
       evaluates pat only once, and thus why we need hist_subst_pattern.
    7. Hence (?(#c$[i++])) matches $i characters at array index $i, and
       we front-anchor that with (#s) and grab a reference to it with
       (#b), then use it in the replacement as $match[1].
    8. Then (j:|:) combines the resulting $#INPUT patterns and ~ makes
       active both the | and the * inserted by :s/.../$match[1]* so the
       whole expansion becomes a single pattern.

Theoretically it should work to use this pattern as a subscript of the
$history associative array with the (r) or (R) subscript flags to find
all matching history events.

-- 
Barton E. Schaefer

Re: Feature request: #a (approximate matching) only for spaces

[Sebastian Gniazdowski]

On 7 December 2015 at 09:22, Bart Schaefer <schaefer@brasslantern.com> wrote:
> Amazingly, you can write that as a one-liner, if you don't count the
> necessity of the setopts and declaring the parameters:
>
>     (${(j:|:)~${i::=1}+${${:-$INPUT"${(@)^${(s::)INPUT}/?/}"}:s/(#b)(#s)(?(#c$[i++]))/$match[1]*}})*

Can be resulting pattern put into $parameter for later use by $~parameter?

Best regards,
Sebastian Gniazdowski

Re: Feature request: #a (approximate matching) only for spaces

[Bart Schaefer]

On Feb 19,  7:21am, Sebastian Gniazdowski wrote:
} Subject: Re: Feature request: #a (approximate matching) only for spaces
}
} On 7 December 2015 at 09:22, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Amazingly, you can write that as a one-liner, if you don't count the
} > necessity of the setopts and declaring the parameters:
} >
} >     (${(j:|:)~${i::=1}+${${:-$INPUT"${(@)^${(s::)INPUT}/?/}"}:s/(#b)(#s)(?(#c$[i++]))/$match[1]*}})*
} 
} Can be resulting pattern put into $parameter for later use by $~parameter?

You might be able to work out a way to do so, but it'd be difficult to get
the quoting right so that arrays were processed before joining etc.

In fact that also may mess up the use of same as an array subscript.  Hm.

Re: Feature request: #a (approximate matching) only for spaces

[Bart Schaefer]

On Feb 19, 11:13am, Bart Schaefer wrote:
} Subject: Re: Feature request: #a (approximate matching) only for spaces
}
} On Feb 19,  7:21am, Sebastian Gniazdowski wrote:
} } 
} } Can be resulting pattern put into $parameter for later use by $~parameter?
} 
} You might be able to work out a way to do so, but it'd be difficult to get
} the quoting right so that arrays were processed before joining etc.

Fiddled with this a little; here's the formulation that can be assigned
(in double quotes) to a parameter and/or used with $ary[(R)pattern]:

(${(j:|:)${i::=1}+${(@)${:-$INPUT"${(@)^${(s::)INPUT}/?/}"}:s/(#b)(#s)(?(#c$[i++]))/${match[1]}*}})*

So for example in the zsh source tree:

torch% () {
function> integer i=0
function> local INPUT=con
function> local -a files=(*) match
function> print -r --
$files[(R)(${(j:|:)~${i::=1}+${(@)${:-$INPUT"${(@)^${(s::)INPUT}/?/}"}:s/(#b)(#s)(?(#c$[i++]))/${match[1]}*}})*]
function> }
config.status
torch% 

All that was really necessary was to add (@) after +${ but note that any
pattern characters in $INPUT will become active again in the subscript.

Re: Feature request: #a (approximate matching) only for spaces

[Bart Schaefer]

On Feb 20, 11:16am, Bart Schaefer wrote:
}
} All that was really necessary was to add (@) after +${ but note that any
} pattern characters in $INPUT will become active again in the subscript.

Oh, to prevent that change that same (@) to (b@):

"(${(j:|:)~${i::=1}+${(b@)${:-$INPUT"${(@)^${(s::)INPUT}/?/}"}:s/(#b)(#s)(?(#c$[i++]))/${match[1]}*}})*"

Re: Feature request: #a (approximate matching) only for spaces

[Sebastian Gniazdowski]

On 7 December 2015 at 09:22, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Dec 7,  5:44am, Mikael Magnusson wrote:
> }
> } % print -l ${~s//(#b)(?)/$match[1]*} # make the pattern g*i*t*p*u*r*g*e*
>
> Yeah, but that also matches gfooifootfooifoopfooufoorfoogfooefoo, which
> I'm not sure is what Sebastian wants.  The pattern

Specifically, it also matches: git pull origin master :) I wonder how
close one can get with patterns to recently popular fuzzy matching. I
guess it's not possible, but maybe miracles happen?

Best regards,
Sebastian Gniazdowski

Re: Feature request: #a (approximate matching) only for spaces

[Sebastian Gniazdowski]

Being skeptical from the beginning, I've just found that fuzzy
matching might not be much better. Doing lsof | fzf and searching for
"listen tcp", gives:

Spotify     459 sgniazdowski   48u    IPv4 0x641c23b7a67dd4e3
0t0       TCP localhost:4371 (LISTEN)

but also tons of other stuff like:

firefox   82115 sgniazdowski  txt      REG                1,1
94656 133710834 /Library/Fonts/DecoTypeNaskh.ttc

where "Library/Fonts/DecoTypeN" is matched. That's even worse than
*a*b*c..., there is no "*l*i*s*t*e*n*t*c*p*" embedded. Guess that what's
important is degree of similarity and showing reasonable matches
first.

Best regards,
Sebastian Gniazdowski


On 8 May 2016 at 08:13, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> On 7 December 2015 at 09:22, Bart Schaefer <schaefer@brasslantern.com> wrote:
>> On Dec 7,  5:44am, Mikael Magnusson wrote:
>> }
>> } % print -l ${~s//(#b)(?)/$match[1]*} # make the pattern g*i*t*p*u*r*g*e*
>>
>> Yeah, but that also matches gfooifootfooifoopfooufoorfoogfooefoo, which
>> I'm not sure is what Sebastian wants.  The pattern
>
> Specifically, it also matches: git pull origin master :) I wonder how
> close one can get with patterns to recently popular fuzzy matching. I
> guess it's not possible, but maybe miracles happen?
>
> Best regards,
> Sebastian Gniazdowski