v67 search/create bar resetting text - impossible to search for/create desired term
Completed
Mac OS: 10.15.6
nVUltra Build: v67
Just updated to v67. Also restarted nvUltra a couple of times. There seems to be a big with the search/create bar. If I enter a search term or try to create a filename that matches one that already exists, it constantly resets the text, so effectively switches to a live updating first letter search. It's only once I type a term that no longer matches a filename that the typed name sticks. I use a big folder of plaintext files as my database and rely on searching for the ones I want, which I can't do right now.
Here's a video to show what's going on. I'm trying to type the word "notes" to search for a filename with that in the title:
https://www.dropbox.com/s/n4n7w40j093mnhm/nvUltra-search-bug.mov?dl=0
Maybe an autocomplete problem?
Cheers,
Andy
-
Weirdly, this only happens to me when the letter "n" is the first letter, although I have not tried the entire alphabet.
What letters is it happening for you Andy Polaine ?
0 -
Well spotted! Yes, that's the case with me too. Only searches starting with n.
0 -
Also words starting with L or S
0 -
Interesting... for me it seems to only be N. L and S work fine.
At first I thought special character in the file name, like an ampersand, but that did not recreate it. Could some special character in a file itself cause this?
0 -
I've had a busy stretch between day job and family commitments, and trying to catch up.
I have to say, reading some of the theories is really interesting. :) It has nothing to do with which letters per se, it has to do with typing a word that does or does not match an existing filename, triggering the autocompletion and incorrectly highlighting the entire filename, moving the cursor back to the beginning.
I'll work on a fix. Will probably be in the "next, next" release since there is a crash for some people that we want to push out since it's ready (68) and then will push another update soon that fixes this and a few other issues (69).
Thanks!
0 -
Thanks Fletcher. Nice to know it’s reproducible and the story behind it.
0 -
Thank you!
I don't really get what you mean (and I don't need to)... curious that it happens in some cases but not others, that was what was hard to understand...
0 -
It happens every time, in the situation in which it happens... ;) Once you see the pattern/cause, it's easy to predict when it will occur and when it will not. But yes, until you see that, it seems rather mysterious.
In any event, I just need to fix that part of the code and it should be solved. Need to coordinate with a few other changes to the search bar.
Again, thanks to all for pointing this out!
0 -
Ok, just because I like this kind of challenge to keep my brain sharp... I think the pattern is when what you are typing matches an existing file that has no extension. Yes?
0 -
No. It has to do with typing a pattern that matches the prefix of one file, but then typing a subsequent letter that matches a different file than the one at the top of the list (thereby choosing a different filename to autocomplete, and inadvertently resetting the selected text range in the search field). It will vary based on your chosen sort order.
0 -
I dug into the code to fix this, and realized there is one additional step required to trigger this. When typing a character that causes a non-text file to be autocompleted, then the full contents of the search bar are selected. Which means that the next keystroke starts over.
So one reason that "n" triggers it for some folks (including me) is autocompleting "Notes & Settings" if you've used nvAlt in the same folder.
Fixed for next release. Thanks to all for pointing this out!
0 -
Aha! Thanks for letting us know the cause.
0
Please sign in to leave a comment.
Comments
12 comments