Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Space in search should be interpreted as _another_ substring #175

Closed
alexanderadam opened this issue Aug 29, 2018 · 11 comments
Closed

Space in search should be interpreted as _another_ substring #175

alexanderadam opened this issue Aug 29, 2018 · 11 comments

Comments

@alexanderadam
Copy link

alexanderadam commented Aug 29, 2018

Thank you for KeePassDX. I love it!

There's just one small issue that bothers me:
So in case someone has a key like "abc def ghi jkl" a search for "abc ghi" won't find anything in KeePassDX (it will find something in other KeePass implementations).

Thank you and have a wonderful day!

@J-Jamet
Copy link
Member

J-Jamet commented Feb 4, 2022

This is not available with a traditional search because items may contain spaces. We would have to implement regexes but this is not urgent at the moment.

@alexanderadam
Copy link
Author

This is not available with a traditional search because items may contain spaces.

This is trivial with databases like SQLite but even with a traditional search a search string "abc def" would simply become the regex Regex("abc.*def", IGNORE_CASE, DOT_MATCHES_ALL) (so the whitespace would be replaced by the match-all-dot and the asterisk for unspecified amount) and it would still find everything that was found before in addition to the new matches.

But of course I'm not Kotlin programmer so I have no clue whether this is much more complicated in Kotlin than in other languages. 😞

this is not urgent at the moment.

Well, this issue is open since 2018 so it's obviously not that urgent. 😆

@J-Jamet
Copy link
Member

J-Jamet commented Feb 4, 2022

Haha, yes I'm reopening the debate because I'm redoing the real time search system with filters, so the regex are forced to adapt to the filters applied with the new model, that's why I bring it up. It wasn't necessarily clear but it allows me to keep track of the issues I looked at.

@alexanderadam
Copy link
Author

I see. I changed my workflow now anyway since I'm since I started using KeePassDX.
So that on mobile devices I won't type more terms (like in the other KeePass clients) but I try to remember just to type one term and then scroll and search manually through the list of results.

It's obviously much slower to find something but at least I'm not ending up without any results. 😆

@J-Jamet
Copy link
Member

J-Jamet commented Feb 4, 2022

Okay, that's very interesting feedback. I didn't implement the Regex because I wanted to partition the developments but in relation to your usage, I'll look into it further so that I don't have any performance issues for the real-time filters.

(I also have to say that I've been doing a lot of work on the search and I'm getting a little tired of that feature. But at least it is now possible to search in the current group and filter most of the fields.)

@J-Jamet
Copy link
Member

J-Jamet commented Feb 19, 2022

Now possible to manage regex since version 3.3.0

@J-Jamet J-Jamet closed this as completed Feb 19, 2022
@alexanderadam
Copy link
Author

Now possible to manage regex since version 3.3.0.

I'm running the F-Droid build version 3.3.1 but it doesn't seem to work.
Should the search strings split by spaces per default or do I have to activate anything somewhere?

@J-Jamet
Copy link
Member

J-Jamet commented Mar 20, 2022

It is the regex search that is implemented, you just have to activate it dynamically. Then you can use it to do your special searches as you said in a previous comment. (ie : abc.*def)

@alexanderadam
Copy link
Author

alexanderadam commented Mar 22, 2022

It is the regex search that is implemented, you just have to activate it dynamically.

How can I activate it dynamically?

Then you can use it to do your special searches as you said in a previous comment. (ie : abc.*def)

I'm not quite sure whether we have a misunderstanding here. 😆
I was not proposing that someone would like to type regular expressions on a mobile phone. I was just proposing that two words in a search string, divided by a whitespace should match both. They shouldn't be kept as a single search token but rather as separate ones.

What I wrote was

a search string "abc def" would simply become the regex Regex("abc.*def", IGNORE_CASE, DOT_MATCHES_ALL) (so the whitespace would be replaced by the match-all-dot and the asterisk for unspecified amount) and it would still find everything that was found before in addition to the new matches.

Therefore I thought that every time I would type "abc def" KeePass could replace whitespaces with .*. So that the example string would look like "abc.*def".
Then it could use this String to do a regexp search without having to activate something.

But I just learned on StackOverflow though that a match all regexp would even work more elegant: independent from their position (I'm not very good with these lookahead statements).

Thus the regular expression could be created like this

  1. the search string (i.e. "abc def") would be splitted by the whitespaces (:arrow_right: ["abc", "def"])
  2. each string in the array would be surrounded by (?=.*\b and \b) (:arrow_right: ["(?=.*\babc\b)", "(?=.*\bdef\b)"])
  3. concatenated again to a single string without(!) whitespaces inbetween (:arrow_right: "(?=.*\babc\b)(?=.*\bdef\b)")
  4. prepended by ^ and appended by .+ (:arrow_right: "^(?=.*\babc\b)(?=.*\bdef\b).+")

It might look cryptic but according to this answer it will match a string independent from the order.

Thus, if your KeePass item title is "Onlinebanking (Superbank)" you could search for superbank online and would still find the correct record.

@J-Jamet
Copy link
Member

J-Jamet commented Mar 25, 2022

I understood what you wanted but the problem is that it changed the current behavior, so users who use the search in a different way than you would not have the same result. I did indicate that this will be the functionality of Regex that will be implemented : #175 (comment)

By leaving the possibility of using Regex, it will be possible to do any type of search in addition to the default one.

To activate it, click on the three-dash icon to the right of the search field and then on the Regex button.
It can be activated by default for the next searches when I will have implemented the issue #1254

@alexanderadam
Copy link
Author

I understood what you wanted but the problem is that it changed the current behavior, so users who use the search in a different way than you would not have the same result.

Actually they would have the exact same result in all cases except when they're using whitespaces.
Because the current implementation doesn't work as excepted and as known in any other KeePass client that I'm aware of (try KeePass2, KeePassX or KeePassXC as a comparison).

I did indicate that this will be the functionality of Regex that will be implemented : #175 (comment)

You're right as you wrote:

This is not available with a traditional search because items may contain spaces.

Which is exactly what I'm referring to. The current behaviour that whitespaces are kept as part of the exact search string differs from every other KeePass client.

By leaving the possibility of using Regex, it will be possible to do any type of search in addition to the default one.

That's nice indeed, but

  1. the default search would still differ from every other KeePass client and is very counterintuitive
  2. typing regular expressions on mobile phones is probably a rare case (but I admit that it might be useful in huge databases)

To activate it, click on the three-dash icon to the right of the search field and then on the Regex button

Ah nice. I never recognized this.

@J-Jamet J-Jamet reopened this Mar 25, 2022
J-Jamet added a commit that referenced this issue Apr 4, 2022
@J-Jamet J-Jamet closed this as completed Apr 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants