Bug: 'Save Current Search' includes entire name of first result instead of only what was typed
Completed
Love the new Save Search feature!
First issue I encountered was if you search for a string that is exactly the beginning of a current note, e.g.:
NV
it saves that entire first search result instead of ONLY what was typed. So the query might become:
NVAlt
rather than showing me:
- NVAlt
- NVUltra
Of course, editing it afterwards fixes this.
...
Beyond that:
1. I believe it was intentional for the keyboard shortcuts NOT to trigger when cursor is in the editor (so those shortcuts can be reserved for other options – header levels?), but probably good to make this explicit in documentation.
2. made me pine more for regex search!
-
1. Correct -- The shortcuts work when in the search bar or the notes list, not the editor or other locations.
2. Saving the search saves whatever is in the search bar. I think the actual problem here is that the refactored search bar still autocompletes when hitting delete. That is now fixed. So if you want to save only "nv" then you could type "nvu" and then delete once so that only "nv" is showing. Trying to guess which part of the search you intend to save is probably not a good idea on our part... ;)
<Technical details follow...>
3. nvUltra indexes the files in your folder to improve search performance and prevent having to read the disk each time you search. Implementing full regular expression search would require storing the full text of each document in the index (which makes it pretty useless as an "index" since it is now a full copy of your files.). (Alternatively, I guess you could do a first pass index that rules out some of the options, and then run the actual regular expression against the full documents for the possible matches. But again, depending on your folder size, this could be painful on a keystroke by keystroke basis.). For small folders of short documents, this isn't too costly in terms of memory or disk space, but as you have larger numbers of larger files, it would start to get slower or take lots more memory. Which would probably not work very well on iOS or other resource constrained systems. Right now the search process is fast, and the indexing process is relatively fast. Equally important, the indexes themselves are relatively small for the accuracy we get (nvUltra's search algorithm is guaranteed to find all matches for a query, but has a calculated false positive rate of less than 2 in 10,000). Also, the index has to be configured in such a way that you match partial words as you type (e.g. you can't just index "foo", you have to index "f", "fo", and "foo".)
In short -- I am definitely open to ways to improve the indexing and search functionality, but will want discussions based on actual implementation ideas, not just "it would be great if you could search by ***". It looks like Google did something like the "use an index as a first pass screen, and then regexp the actual text" approach, but even they stopped doing it. Which says something....
In particular, I am looking for fast indexing and search, with low disk space requirements and low memory requirements. Oh, and it should be reasonably easy to implement in a cross-platform C library. I've read a lot about this, but am by no means an expert. So would love to hear newer ideas from those in the know!!
By way of comparison... I have a 180 MB folder (largely text and PDF documents) which requires 815 KB on disk to index (which means on the order of 815 KB in RAM when the index is loaded for use). The indices for all 14 folders I use in nvUltra require approximately 4.8 MB in total. And that is actually 2 indices per folder, since the similarity index is configured differently than the search index.
0 -
Hi Fletcher Penney – thanks for weighing in so quickly!
On:
2. So did you mean that is fixed in next update? For me, if I type beginning of an existing filename, then delete any number of characters > Save search. It highlights then saves the entire existing filename.
Also on 2, the additional buggy behaviour that I couldn't reproduce consistently so didn't mention it happens now when I quite NVUltra, re-open and immediately trigger one of the saved searches and start scrolling, after a couple seconds it removes all the initial search results and only shows the first one.
3. That sounds perfectly reasonable, speed of search is far more fundamental to NV. I wonder is it possible to at least allow explicit searches between "search terms". For instance, I have a probably dumb pattern now of prefacing a lot of notes with:
R - name of reference file
L - name of task list
If not, I may just bulk rename these without the spaces.
0 -
2. Correct. I have not yet (will not have yet?) invented time travel. So it was fixed after your message and before my response.
3. You mean like if you type `"search terms"` into the search bar? ;). (Though the current exact match only searches contents. I have added file name searching since you mentioned it.)
As for your bug report -- do you cache indexing? If not, as the index is updated it has to apply the search criteria as new files are indexed. Which, by the time you have finished might mean that the search bar now contains the entire filename of the first match. Cache the index, and then you won't have to reindex.
If you are caching the index, I can only assume you are applying the saved search before the ink is dry on the window as it is opened..... Just give it a couple of milliseconds..... ;)
0
Please sign in to leave a comment.
Comments
3 comments