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.
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,
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
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
(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'
