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.&alphanum)'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 <[email protected]> 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
