Re: [Jgeneral] qtide name only search issues
Hmm...
I do see a difference, and I see a problem with the definition itself.
To test, I created a small file containing:
n_
n.
return.
Using the old jqt, a search for n. will find a match on the second and
third row (which is expected). A name only search for n. will only
match the first row.
Using the new jqt, a name-only search for n. finds nothing.
I think the problem is that the \b zero length pattern does not match
on the right hand side of the . character.
I guess the solution would be to introduce an alternative terminating
pattern when the name ends in a character ch which is !isalnum(ch)
(isalnum needs #include but that's standard on every system
with a c compiler, and might already be included... Anyways, this
would allow the search to remain meaningful for arbitrary tokens
parsed by ;: even if they are not currently meaningful in the
language.)
I hope this helps,
--
Raul
On Sun, Oct 9, 2022 at 2:38 PM chris burke wrote:
>
> I made those changes, but don't see any difference in the search.
> Please check, thanks.
>
> See
> https://github.com/jsoftware/qtide/commit/1ace6d8fea79f74ea73be4db8d992cbbca5efff9
>
> builds at https://github.com/jsoftware/qtide/releases/tag/build
>
> On Sat, Oct 8, 2022 at 6:24 PM Raul Miller wrote:
> >
> > It might be good enough to change Rxnna and Rxnnz at
> > https://github.com/jsoftware/qtide/blob/master/lib/base/state.cpp#L189
> > to
> >
> > Rxnna = "\\b\\Q";
> > Rxnnz = "\\E\\b";
> >
> > There's an obscure edge case here, if someone tries searching for a
> > "name" containing \E but that should never happen.
> >
> > Thanks,
> >
> > --
> > Raul
> >
> > On Sat, Oct 8, 2022 at 8:44 PM chris burke wrote:
> > >
> > > The name only search is a regex of \b (word boundary) at start and end
> > > of the string, see
> > >
> > > https://github.com/jsoftware/qtide/blob/master/lib/base/fiw.cpp line 363
> > >
> > > and
> > >
> > > https://github.com/jsoftware/qtide/blob/master/lib/base/state.cpp line
> > > 189.
> > >
> > > Perhaps a better regex could be taken from
> > >
> > > https://github.com/jsoftware/base9/blob/master/regex/regj.ijs
> > >
> > > and maybe this needs updating as well.
> > >
> > > On Sat, Oct 8, 2022 at 10:19 AM Raul Miller wrote:
> > > >
> > > > An additional problem here is that a name only search for m. will
> > > > treat the . as a wildcard character rather than matching specifically
> > > > on the . character.
> > > >
> > > > This is probably due to the use of a regular expression in the
> > > > implementation without the use of a regular expression quoting
> > > > mechanism for the name part.
> > > >
> > > > In J, this quoting mechanism could look like
> > > >
> > > > alphanum=. '0123456789',(#~ tolower~:toupper)a.
> > > > quotere=: {{1}.(#!.'\'~1 j. 1|.-.@e.)'x',y}}
> > > >
> > > > (In other words: precede every non-alphanumeric character with a
> > > > backslash.)
> > > >
> > > > FYI,
> > > >
> > > > --
> > > > Raul
> > > >
> > > > On Sat, Oct 8, 2022 at 12:51 PM Raul Miller
> > > > wrote:
> > > > >
> > > > > (I am not sure where I should leave these observations.)
> > > > >
> > > > > Today, I stumbled over a couple mis-features in the implementation of
> > > > > the "name only" mechanism in j's qtide search mechanism.
> > > > >
> > > > > One issue is that a "name only" search for 'm' finds the 'm' in 'm.'
> > > > > This makes searching for instances of 'm' which are not 'm.'
> > > > > interesting, but arguably this is an acceptable compromise because J
> > > > > merged 'm.' into 'm' some time ago.
> > > > >
> > > > > However, a "name only" search for 'm' does not find the 'm' in
> > > > > 'var__m' (quotes are for emphasis here, and would not appear in the
> > > > > text being searched), nor does a name only search for 'i' find the 'i'
> > > > > in 'for_i.'.
> > > > >
> > > > > Anyways, at some point, I think we should do better here.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > --
> > > > > Raul
> > > > --
> > > > For information about J forums see http://www.jsoftware.com/forums.htm
> > > --
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] qtide name only search issues
I made those changes, but don't see any difference in the search.
Please check, thanks.
See
https://github.com/jsoftware/qtide/commit/1ace6d8fea79f74ea73be4db8d992cbbca5efff9
builds at https://github.com/jsoftware/qtide/releases/tag/build
On Sat, Oct 8, 2022 at 6:24 PM Raul Miller wrote:
>
> It might be good enough to change Rxnna and Rxnnz at
> https://github.com/jsoftware/qtide/blob/master/lib/base/state.cpp#L189
> to
>
> Rxnna = "\\b\\Q";
> Rxnnz = "\\E\\b";
>
> There's an obscure edge case here, if someone tries searching for a
> "name" containing \E but that should never happen.
>
> Thanks,
>
> --
> Raul
>
> On Sat, Oct 8, 2022 at 8:44 PM chris burke wrote:
> >
> > The name only search is a regex of \b (word boundary) at start and end
> > of the string, see
> >
> > https://github.com/jsoftware/qtide/blob/master/lib/base/fiw.cpp line 363
> >
> > and
> >
> > https://github.com/jsoftware/qtide/blob/master/lib/base/state.cpp line 189.
> >
> > Perhaps a better regex could be taken from
> >
> > https://github.com/jsoftware/base9/blob/master/regex/regj.ijs
> >
> > and maybe this needs updating as well.
> >
> > On Sat, Oct 8, 2022 at 10:19 AM Raul Miller wrote:
> > >
> > > An additional problem here is that a name only search for m. will
> > > treat the . as a wildcard character rather than matching specifically
> > > on the . character.
> > >
> > > This is probably due to the use of a regular expression in the
> > > implementation without the use of a regular expression quoting
> > > mechanism for the name part.
> > >
> > > In J, this quoting mechanism could look like
> > >
> > > alphanum=. '0123456789',(#~ tolower~:toupper)a.
> > > quotere=: {{1}.(#!.'\'~1 j. 1|.-.@e.)'x',y}}
> > >
> > > (In other words: precede every non-alphanumeric character with a
> > > backslash.)
> > >
> > > FYI,
> > >
> > > --
> > > Raul
> > >
> > > On Sat, Oct 8, 2022 at 12:51 PM Raul Miller wrote:
> > > >
> > > > (I am not sure where I should leave these observations.)
> > > >
> > > > Today, I stumbled over a couple mis-features in the implementation of
> > > > the "name only" mechanism in j's qtide search mechanism.
> > > >
> > > > One issue is that a "name only" search for 'm' finds the 'm' in 'm.'
> > > > This makes searching for instances of 'm' which are not 'm.'
> > > > interesting, but arguably this is an acceptable compromise because J
> > > > merged 'm.' into 'm' some time ago.
> > > >
> > > > However, a "name only" search for 'm' does not find the 'm' in
> > > > 'var__m' (quotes are for emphasis here, and would not appear in the
> > > > text being searched), nor does a name only search for 'i' find the 'i'
> > > > in 'for_i.'.
> > > >
> > > > Anyways, at some point, I think we should do better here.
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > Raul
> > > --
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] qtide name only search issues
It might be good enough to change Rxnna and Rxnnz at
https://github.com/jsoftware/qtide/blob/master/lib/base/state.cpp#L189
to
Rxnna = "\\b\\Q";
Rxnnz = "\\E\\b";
There's an obscure edge case here, if someone tries searching for a
"name" containing \E but that should never happen.
Thanks,
--
Raul
On Sat, Oct 8, 2022 at 8:44 PM chris burke wrote:
>
> The name only search is a regex of \b (word boundary) at start and end
> of the string, see
>
> https://github.com/jsoftware/qtide/blob/master/lib/base/fiw.cpp line 363
>
> and
>
> https://github.com/jsoftware/qtide/blob/master/lib/base/state.cpp line 189.
>
> Perhaps a better regex could be taken from
>
> https://github.com/jsoftware/base9/blob/master/regex/regj.ijs
>
> and maybe this needs updating as well.
>
> On Sat, Oct 8, 2022 at 10:19 AM Raul Miller wrote:
> >
> > An additional problem here is that a name only search for m. will
> > treat the . as a wildcard character rather than matching specifically
> > on the . character.
> >
> > This is probably due to the use of a regular expression in the
> > implementation without the use of a regular expression quoting
> > mechanism for the name part.
> >
> > In J, this quoting mechanism could look like
> >
> > alphanum=. '0123456789',(#~ tolower~:toupper)a.
> > quotere=: {{1}.(#!.'\'~1 j. 1|.-.@e.)'x',y}}
> >
> > (In other words: precede every non-alphanumeric character with a backslash.)
> >
> > FYI,
> >
> > --
> > Raul
> >
> > On Sat, Oct 8, 2022 at 12:51 PM Raul Miller wrote:
> > >
> > > (I am not sure where I should leave these observations.)
> > >
> > > Today, I stumbled over a couple mis-features in the implementation of
> > > the "name only" mechanism in j's qtide search mechanism.
> > >
> > > One issue is that a "name only" search for 'm' finds the 'm' in 'm.'
> > > This makes searching for instances of 'm' which are not 'm.'
> > > interesting, but arguably this is an acceptable compromise because J
> > > merged 'm.' into 'm' some time ago.
> > >
> > > However, a "name only" search for 'm' does not find the 'm' in
> > > 'var__m' (quotes are for emphasis here, and would not appear in the
> > > text being searched), nor does a name only search for 'i' find the 'i'
> > > in 'for_i.'.
> > >
> > > Anyways, at some point, I think we should do better here.
> > >
> > > Thanks,
> > >
> > > --
> > > Raul
> > --
> > For information about J forums see http://www.jsoftware.com/forums.htm
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] qtide name only search issues
The name only search is a regex of \b (word boundary) at start and end
of the string, see
https://github.com/jsoftware/qtide/blob/master/lib/base/fiw.cpp line 363
and
https://github.com/jsoftware/qtide/blob/master/lib/base/state.cpp line 189.
Perhaps a better regex could be taken from
https://github.com/jsoftware/base9/blob/master/regex/regj.ijs
and maybe this needs updating as well.
On Sat, Oct 8, 2022 at 10:19 AM Raul Miller wrote:
>
> An additional problem here is that a name only search for m. will
> treat the . as a wildcard character rather than matching specifically
> on the . character.
>
> This is probably due to the use of a regular expression in the
> implementation without the use of a regular expression quoting
> mechanism for the name part.
>
> In J, this quoting mechanism could look like
>
> alphanum=. '0123456789',(#~ tolower~:toupper)a.
> quotere=: {{1}.(#!.'\'~1 j. 1|.-.@e.)'x',y}}
>
> (In other words: precede every non-alphanumeric character with a backslash.)
>
> FYI,
>
> --
> Raul
>
> On Sat, Oct 8, 2022 at 12:51 PM Raul Miller wrote:
> >
> > (I am not sure where I should leave these observations.)
> >
> > Today, I stumbled over a couple mis-features in the implementation of
> > the "name only" mechanism in j's qtide search mechanism.
> >
> > One issue is that a "name only" search for 'm' finds the 'm' in 'm.'
> > This makes searching for instances of 'm' which are not 'm.'
> > interesting, but arguably this is an acceptable compromise because J
> > merged 'm.' into 'm' some time ago.
> >
> > However, a "name only" search for 'm' does not find the 'm' in
> > 'var__m' (quotes are for emphasis here, and would not appear in the
> > text being searched), nor does a name only search for 'i' find the 'i'
> > in 'for_i.'.
> >
> > Anyways, at some point, I think we should do better here.
> >
> > Thanks,
> >
> > --
> > Raul
> --
> For information about J forums see http://www.jsoftware.com/forums.htm
--
For information about J forums see http://www.jsoftware.com/forums.htm
Re: [Jgeneral] qtide name only search issues
An additional problem here is that a name only search for m. will
treat the . as a wildcard character rather than matching specifically
on the . character.
This is probably due to the use of a regular expression in the
implementation without the use of a regular expression quoting
mechanism for the name part.
In J, this quoting mechanism could look like
alphanum=. '0123456789',(#~ tolower~:toupper)a.
quotere=: {{1}.(#!.'\'~1 j. 1|.-.@e.)'x',y}}
(In other words: precede every non-alphanumeric character with a backslash.)
FYI,
--
Raul
On Sat, Oct 8, 2022 at 12:51 PM Raul Miller wrote:
>
> (I am not sure where I should leave these observations.)
>
> Today, I stumbled over a couple mis-features in the implementation of
> the "name only" mechanism in j's qtide search mechanism.
>
> One issue is that a "name only" search for 'm' finds the 'm' in 'm.'
> This makes searching for instances of 'm' which are not 'm.'
> interesting, but arguably this is an acceptable compromise because J
> merged 'm.' into 'm' some time ago.
>
> However, a "name only" search for 'm' does not find the 'm' in
> 'var__m' (quotes are for emphasis here, and would not appear in the
> text being searched), nor does a name only search for 'i' find the 'i'
> in 'for_i.'.
>
> Anyways, at some point, I think we should do better here.
>
> Thanks,
>
> --
> Raul
--
For information about J forums see http://www.jsoftware.com/forums.htm
[Jgeneral] qtide name only search issues
(I am not sure where I should leave these observations.) Today, I stumbled over a couple mis-features in the implementation of the "name only" mechanism in j's qtide search mechanism. One issue is that a "name only" search for 'm' finds the 'm' in 'm.' This makes searching for instances of 'm' which are not 'm.' interesting, but arguably this is an acceptable compromise because J merged 'm.' into 'm' some time ago. However, a "name only" search for 'm' does not find the 'm' in 'var__m' (quotes are for emphasis here, and would not appear in the text being searched), nor does a name only search for 'i' find the 'i' in 'for_i.'. Anyways, at some point, I think we should do better here. Thanks, -- Raul -- For information about J forums see http://www.jsoftware.com/forums.htm
