find – EmEditor (Text Editor) https://www.emeditor.com Best Text Editor, Code Editor, CSV Editor, Large File Viewer for Windows (Free versions available) Sun, 26 Nov 2023 22:32:57 +0000 en-US hourly 1 https://wordpress.org/?v=6.5.5 Search function https://www.emeditor.com/forums/topic/search-function/ Sun, 26 Nov 2023 22:32:03 +0000 https://www.emeditor.com/forums/topic/search-function/ It is convenience to make “Find” window in always on top. However, it will block text under the window after finding. Is it possible to make the “Find” window in semi-transparent when it is inactive?

]]>
Search Functionality Improvement Suggestion: Allow Multiple Findings Highlighted https://www.emeditor.com/forums/topic/search-functionality-improvement-suggestion-allow-multiple-findings-highlighted/ Fri, 01 Mar 2019 16:18:22 +0000 https://www.emeditor.com/forums/topic/search-functionality-improvement-suggestion-allow-multiple-findings-highlighted/ Hi there,
Unless it is lurking somewhere in the settings, I am missing badly the Notepad++ feature that highlights all the found strings, hence is my search functionality improvement suggestion –
allow multiple found strings highlighted after search /replace.
Thanks

]]>
Find/Replace should have a checkbox to ignore comments https://www.emeditor.com/forums/topic/findreplace-should-have-a-checkbox-to-ignore-comments/ Tue, 08 Aug 2017 18:57:57 +0000 https://www.emeditor.com/forums/topic/findreplace-should-have-a-checkbox-to-ignore-comments/ So many editors lack this intuitive feature! If I want to search for a string in code, I might want to find it only in the code, not within comments. It should be easy: don’t search anything that’s colored as a comment according to the Highlight (2) options.

]]>
Find dialog issue https://www.emeditor.com/forums/topic/find-dialog-issue/ Fri, 21 Jul 2017 06:57:37 +0000 https://www.emeditor.com/forums/topic/find-dialog-issue/ I press Ctrl+F and I search for something. Once I find it, I press Esc, I make my correction, and then press Ctrl+F to find the next instance. However, the “Find:” text box has different text populated now and I have to scroll in order to find the text I searched originally. Is there anyway to make it stick to the latest searched text?

]]>
Bug in regular expression find, both in green-coloring and actual finding https://www.emeditor.com/forums/topic/bug-in-regular-expression-find-both-in-green-coloring-and-actual-finding/ Thu, 14 Jul 2016 23:32:49 +0000 https://www.emeditor.com/forums/topic/bug-in-regular-expression-find-both-in-green-coloring-and-actual-finding/ While trying to search for “lines not beginning with a tab, and also followed by an empty line”, I found some strange behavior in the EmEditor Find function that clearly seems like bugs to me, as follows:

The following regular expression works as expected (finds and colors green all lines that do not begin with a tab):

^[^\t].*

As soon as I add a linebreak though, the green-coloring of search results stops working completely. The actual finding of the lines still works though (the lines are selected in grey and jumped to correctly when pressing “Find next”):

^[^\t].*\n

If adding another linebreak to the regular expression though, both the green-coloring and the correct finding of the lines stop working completely though, and seemingly completely random lines are identified as “found” (I tried bookmarking the found lines from the Find dialog, since this was the only way of identifying them at all with the highlighting not working correctly):

^[^\t].*\n\n

I am not using any special search settings, and all checkboxes are unchecked in the “Advanced…” dialog of the Find dialog. Also I tried using both regular expression engines without any difference.

ADDITION:
I just noticed that the inability to find the correct lines happens only when the filter function is used (typically when there is really a line following the seemingly single lines, but it has been filtered away), but the lack-of-green-coloring bug happens no matter if there is a filter applied or not, so it’s a separate bug.

Here is a test case:

Try to use the regular expression ^[^\t].*\n\n on the following, without any filtering, and you will see that the green-coloring of search results will be missing:

aaa

bbb

ccc
111

ddd

eee

Now, filter away the line containing the “111” (and a tab before it) and try to search again with the same regexp, and you will see that the “ccc” line will still not be matched, although it should be now (since it is also a “single line” after that filtering-away of the subsequent “111” line).

]]>