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
Case sensitivity of searches in virtual buffers are not preserved with find next #5522
Comments
And a patch in dkager/nvda@d64fb8b. Feel free to not use it and do something far more sophisticated! |
Hi, If I remember right, we had a discussion about this while I was implementing case sensitive find (#4584) last year. I’d say let’s leave it as is unless there is a strong reason to preserve case sensitivity (of course we could have a flag indicating that it is a case sensitive find in cursor manager). Thanks. From: Davy Kager [mailto:notifications@github.com] STR:
— |
My ‘strong reason’ is that if I perform a case sensitive search, then ask for the next result, I expect that next search to also be case sensitive. This is especially true in the log viewer (#4929, which I also worked on today). But also when searching through developer documentation in browse mode, if you are looking for SOMETHING you probably don’t want to find SomeThing with the next search (note the caps). Similarly, it struck me as odd that the last search text is preserved but the state of the case sensitive checkbox isn’t. |
Having given this some more thought I still think this suggestion makes sense: consecutive searches for a phrase should use the same parameters that were used in the initial search for that phrase. Whether a new search should also remember the parameters is a topic of discussion. I think this is useful but I can imagine others may find it confusing. And of course these parameters should not be persistent, i.e. they revert to their defaults when you restart NVDA. Any renewed thoughts on this Joseph? :) I'm not trolling (well, not intentionally). I just ran into real-world cases where I'd like my search parameters to be preserved as described above. For example, when searching in JavaDoc files. |
I don't recall the previous discussion on this, but IMO, if someone is willing to code it, we should preserve this setting (but not across restarts of course). Aside from anything else, this is consistent with other programs that have find functionality. I can't think of any find dialog which doesn't keep the settings across executions. |
In reguards of implantation:
caseSensitive=caseSensitive) to and might be able to remove the whole arguement for caseSensitive from On 1/6/2016 4:04 PM, James Teh wrote:
Websites: email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu |
If you do self.caseSensitive, you're storing it on the instance of the dialog. That instance gets thrown away as soon as it's done, so it won't get preserved across finds. Instead, you need to store it as a class attribute (not an instance attribute) on CursorManager. That also allows you to get rid of the caseSensitive argument to doFindText. |
Done. I will commit tomorrow. Btw, unless anyone objects (doubt it) I am On 1/6/2016 10:43 PM, James Teh wrote:
Websites: email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu |
See pull request https://github.com/nvaccess/nvda/pull/5662/files On 1/6/2016 10:43 PM, James Teh wrote:
Websites: email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu |
Also, the checkbox should get the right selection state based on this attribute of course. See my commit linked to in a comment above, which was rather dirty but shows what I had in mind. From: James Teh [mailto:notifications@github.com] If you do self.caseSensitive, you're storing it on the instance of the dialog. That instance gets thrown away as soon as it's done, so it won't get preserved across finds. Instead, you need to store it as a class attribute (not an instance attribute) on CursorManager. That also allows you to get rid of the caseSensitive argument to doFindText. — |
Oh. We do indeed preserve the text's state as part of the find dialog. I
Websites: email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu |
Just updated the pr. On 1/7/2016 8:16 AM, Davy Kager wrote:
Websites: email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu |
Awesome! From: derekriemer [mailto:notifications@github.com] Just updated the pr. On 1/7/2016 8:16 AM, Davy Kager wrote:
Derek Riemer
Websites: email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu — |
Note that I have a pull request open for this, and in terms of code review, this should be an easy one because there's not that much code. |
Hi, On my way to do code review. From: derekriemer [mailto:notifications@github.com] Note that I have a pull request open for this, and in terms of code review, this should be an easy one because there's not that much code. — |
I think you reviewed the PR for this a while ago and it stalled. We had On 5/6/2016 5:42 PM, josephsl wrote:
Websites: email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu |
Hi, Uh oh, we need to nudge devs a bit then… If there’s virtually no change between the code I reviewed and the new commit, then I’d say we should wait for a little while until @jcsteh can take a look at this further. Thanks. From: derekriemer [mailto:notifications@github.com] I think you reviewed the PR for this a while ago and it stalled. We had On 5/6/2016 5:42 PM, josephsl wrote:
Derek Riemer
Websites: email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu — |
jcsteh commented on Jan 7:
|
STR:
The text was updated successfully, but these errors were encountered: