Re: is it possible to get NEARNESS behavior w/ regex tag search?

--===============2038131718993803233==
Content-Type: multipart/alternative; boundary=001a11401bcc47b7e5054a70f593

--001a11401bcc47b7e5054a70f593
Content-Type: text/plain; charset=UTF-8

Hello,
> I note that NEARNESS feature does not work with -r as "--from-here" does
not
> support the -r option.
...
> At present doing a regex search for "filterThings" does not respect
nearness order,

Since the --nearness is just a sort option, it is independent of type of
search,
I believe. It is helpful if you send a bug report about this to
[email protected].
Thank you in advance.

Regards,
Shigio


2017-03-11 7:22 GMT+09:00 Gautam Thaker <[email protected]>:

> I find the NEARNESS support to be very helpful in that where one has
> multiple definitions of the same token  NEARNESS more often then not find
> the definition I am interested in.
>
> I note that NEARNESS feature does not work with -r as "--from-here" does
> not support the -r option. Is it possible to extend to get this support? I
> have  a system in which I have 10s of definitions of type:
>
> ModuleA_filterThings(){}
> ModuleB_filterThings(){}
>
> I call these methods by reference, in code I have something like:
>
>     r->filterThings();
>
> where correct function pointer has been set so that in typically the
> "nearest" ModuleX_filterThings() would be correct definition.
>
> At present doing a regex search for "filterThings" does not respect
> nearness order, is it too difficult to get this?
>
> GHT
>
>
> _______________________________________________
> Help-global mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/help-global
>
>


-- 
Shigio YAMAGUCHI <[email protected]>
PGP fingerprint:
26F6 31B4 3D62 4A92 7E6F  1C33 969C 3BE3 89DD A6EB (Currently in use)
D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3 (Used until 2017/2)

--001a11401bcc47b7e5054a70f593
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello,</div><div>&gt; I note that NEARNESS feature do=
es not work with -r as &quot;--from-here&quot; does not</div><div>&gt; supp=
ort the -r option.</div><div>...</div><div>&gt; At present doing a regex se=
arch for &quot;filterThings&quot; does not respect nearness order,</div><di=
v><br></div><div>Since the --nearness is just a sort option, it is independ=
ent of type of search,</div><div>I believe. It is helpful if you send a bug=
 report about this to <a href=3D"mailto:[email protected]">bug-global@gnu.=
org</a>.</div><div>Thank you in advance.</div><div><br></div><div>Regards,<=
/div><div>Shigio</div><div><br></div></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">2017-03-11 7:22 GMT+09:00 Gautam Thaker <span dir=
=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">ghthak=
[email protected]</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">I find the NEARNESS support to be very helpful in that where one has m=
ultiple definitions of the same token =C2=A0NEARNESS more often then not fi=
nd the definition I am interested in.<div><br></div><div>I note that NEARNE=
SS feature does not work with -r as &quot;--from-here&quot; does not suppor=
t the -r option. Is it possible to extend to get this support? I have =C2=
=A0a system in which I have 10s of definitions of type:<br><br>ModuleA_filt=
erThings(){}<br>ModuleB_filterThings(){}<br><br></div><div>I call these met=
hods by reference, in code I have something like:<br><br>=C2=A0 =C2=A0 r-&g=
t;filterThings(); =C2=A0<br><br>where correct function pointer has been set=
 so that in typically the &quot;nearest&quot; ModuleX_filterThings() would =
be correct definition.<br><br>At present doing a regex search for &quot;fil=
terThings&quot; does not respect nearness order, is it too difficult to get=
 this?<br><br>GHT</div><div><br></div></div>
<br>______________________________<wbr>_________________<br>
Help-global mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"https://lists.gnu.org/mailman/listinfo/help-global" rel=3D"noref=
errer" target=3D"_blank">https://lists.gnu.org/mailman/<wbr>listinfo/help-g=
lobal</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">=
<div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Sh=
igio YAMAGUCHI &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">shig=
[email protected]</a>&gt;</div><div dir=3D"ltr"><div dir=3D"ltr">PGP fingerprint:=
=C2=A0</div><div dir=3D"ltr">26F6 31B4 3D62 4A92 7E6F =C2=A01C33 969C 3BE3 =
89DD A6EB (Currently in use)</div><div dir=3D"ltr">D1CB 0B89 B346 4AB6 5663=
 =C2=A0C4B6 3CA5 BBB3 57BE DDA3 (Used until 2017/2)</div></div></div></div>=
</div></div></div></div>
</div>

--001a11401bcc47b7e5054a70f593--


--===============2038131718993803233==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Help-global mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-global

--===============2038131718993803233==--