is it possible to get NEARNESS behavior w/ regex tag search?
Gautam Thaker <[email protected]> Fri, 10 Mar 2017 17:22:27 -0500
| Newsgroups | gmane.comp.gnu.global.general |
|---|---|
| Message-ID | <CA+1+E3Ug_56bd8fkN5C441tBEL+T898K2qVSbgp5xYU=XLYbCg@mail.gmail.com> |
--===============3113622037354362657==
Content-Type: multipart/alternative; boundary=94eb2c05e90af9940e054a67cbec
--94eb2c05e90af9940e054a67cbec
Content-Type: text/plain; charset=UTF-8
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
--94eb2c05e90af9940e054a67cbec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I find the NEARNESS support to be very helpful in that whe=
re one has multiple definitions of the same token =C2=A0NEARNESS more often=
then not find the definition I am interested in.<div><br></div><div>I note=
that NEARNESS feature does not work with -r as "--from-here" doe=
s not support 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>Mo=
duleA_filterThings(){}<br>ModuleB_filterThings(){}<br><br></div><div>I call=
these methods by reference, in code I have something like:<br><br>=C2=A0 =
=C2=A0 r->filterThings(); =C2=A0<br><br>where correct function pointer h=
as been set so that in typically the "nearest" ModuleX_filterThin=
gs() would be correct definition.<br><br>At present doing a regex search fo=
r "filterThings" does not respect nearness order, is it too diffi=
cult to get this?<br><br>GHT</div><div><br></div></div>
--94eb2c05e90af9940e054a67cbec--
--===============3113622037354362657==
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
--===============3113622037354362657==--