Hello, @coises and All,
So here are my thoughts on the various points you raised in this post. Of course, these opinions are my own and do not reflect the views of anyone else !
Regarding the obvious missing features :
You said :
Implement Replace in Files in the Search in Files dialocg.
I’m very interested in this feature because the search function is already very flexible: searching by size or date, or selecting files using regex => Thus; this would allow for highly customized replacements !
You said :
Ability to save and recall search strings.
I’d lean toward a configurable number of items, between 1 to 30 maximum, in the history, which, in my opinion, would not be used very often, if the saving S/R feature is implemented !
You said :
Would the ability to “pin” history items be useful? (Simpler and faster than a save process.)
Personally, I think that saving S/R is preferable !
You said :
For saving I’m thinking of controlling that through a dialog that would let you name what you save, so you would then recall it by name. Saving would save the Find and Replace strings and the associated settings. It would have to be possible to edit, rename or delete a saved search as well. Recalling would probably be by selecting from a flyout on the right-click menu. Thoughts? Is that too complicated?
I’m globally very much in favor of this system !
You said :
Should the regular dialog (for searching in documents) and the Search in Files dialog share a single set of saved searches?
The type of search and replace performed on a set of files is generally different from that performed on a single file or on a few files opened in an Notepad++ session => Therefore, if possible, the use of two separate lists would be nice, but don’t bother too much about it !
Regarding the features under consideration :
You said :
1 Context in search results: that is, showing one or more lines before or after the line(s) containing a match.
This would be optional and configurable, but a tricky question is whether it is sufficient to configure it before the search or whether you should be able to request context — either for a specific match or for all matches — directly in the search results window, after the search.
Personally, I suppose that asking for 1 to 5 lines before / after the context, once the search ended, should be sufficient !
You said
It seems like it would make sense for this to be available for Show actions, too.
Yes it would. I agree with your opinion !
You said :
2 Warn or block when characters used in the find or replace fields are inconsistent with the character encoding of files to be searched. (Right now find proceeds without a warning, and replace uses the substitution character, usually a question mark.)
I would say : displays a warning and tell that any non encodable character will be replaced with an interrogation mark !
You said :
Find is tricky, because I would have to parse the regular expression to attempt to determine whether the inconsistent characters are required for a match (so no match is possible) or whether they are only required by some alternatives (which might be intentional, if the same expression is used with files in different encodings). Is it worth doing at all? Would a warning (so I didn’t have to parse, since you could just say to search anyway) be more annoying than helpful?
The more simple , the best ! Don’t analyze files first : just put a warning, before the search, that any non encodable character will be changed into an ? symbol, within the Search++ results panel !
You said :
Replacing can also be conditional, so do I try to detect that, and if it’s conditional, only warn or block if it actually happens? If replacing in multiple files, it could vastly slow down the process if I have to examine each file first to determine its encoding before beginning the actual replace operation. Is it worth it? Or do I only raise the warning if and when I encounter a file that can’t do the replace as written?
As above, just a warning, before the replacement, that any non-encodable character will be replaced with a ? symbol !
You said :
3 In the main search dialog, when the default action is active for a button (e.g., Find, Count, etc. without a scope qualification like “in Selection” or “in Marked Text”), somehow indicate what the default action would be if you pressed the button right now. That is, Find adapts to work in selection if you have a selection large enough, or in marked text, or in the whole document, but what will it actually do right now? This feels like a big missing thing to me, but I’m a bit stumped as to how to indicate it.
If a put a general indicator somewhere (it will always be the same for all buttons with default scope), where, and how should it appear? I am very hesitant to take up additional space in the dialog, or to make it any more “busy” than it already is.
If I show it on each button, how would I distinguish it from the marker that tells you the direct action for the button is a command with a specified scope? (Remember, this has to work for any dark mode color combination the user might pick, and some users are colorblind.)
Would it be better to show it on the buttons and remove the ability to select an action with other than default scope as the action for a button by shift-clicking the drop-down menu? Does anyone even realize they can shift-click the drop-down menus (the only way to know is to do it by accident or read the help)?
Personally, I’m rather in favor of your last point. That way, we would know exactly which operation has just been performed, and it would be really helpful when pressing the Search button , on the right of the Search++ panel — which would clearly indicate whether we’ve selected : a list, a selection, a mark, or just the results of a search !
You said :
Figure out how to modify Boost.regex to get rid of the dreaded “complexity” message. Make progress responsive during a search (not just between finds, as it is now: Boost.regex as built has no progress callback, so you can only estimate progress after it succeeds or fails to find a match, not while it’s working) and let the user cancel if it’s taking too long.
I do not think this point is essential. Check out my post at https://community.notepad-plus-plus.org/post/106252. Apparently, for certain regular expression searches, this specific message, about complexity, may appear (even though the result is correct) when the scanned file contains an average number of lines, with nice results for smaller files and an error for big files !
You said :
5 Figure out how to modify Boost.regex to support Unicode word boundaries, and extend that to plain text searches by translating them into regex searches. (Unicode word boundaries recognize that sequences like “can’t” are a single word; for example, if implemented, a whole word match for “can” wouldn’t match the first three letters of ”can’t”; at present, it does.)
This point does not seem essential either, at least at first !
You said :
6 Implement “Unicode compatibility forms” matching. This means being able to search for something like “naive” and have it match “naïve” (or vice versa). I think I would only attempt to implement this, at least at first, for plain text searches (which would be translated to a regular expression the user would not see).
This option seems interesting, and I’m definitely in favor of it!
Regarding the Deficiencies and bugs :
You said :
1 Personally, I really like the Show function. It hides all lines and then shows the ones that have matches, also marking the matches. A bit like a Find All with the results list right in the document instead of in a tiny little window at the bottom. But there are problems. I use Scintilla’s hidden lines feature directly. Notepad++ also uses that feature, but it doesn’t provide a way for plugins to use it through Notepad++, and it keeps internal status information that assumes only it is using hidden lines. There appears to be no way to make Notepad++ synchronize its own idea of which lines it thinks are hidden with the actual state of Scintilla. Various bizarre things happen because of this. That leaves me with four choices, none of which are great:
Remove the Show function entirely.
Accept that if you use Show, unintended and illogical things can and will happen.
Petition Don to provide a way for plugins to use hidden lines without confusing Notepad++, which might not be accepted, would probably take a long time even if it is accepted, and even when completed would mean this would only work correctly on versions of Notepad++ at least that new.
Get “creative” and look for some back-door, hacky way to fix it (which might or might not be possible, and might break without warning when Notepad++ changesc something).
I would keep option 2 ( Accept the SHOW feature as is ) and, eventually, ask @DonHo about the hidden lines !
You said :
2 Keyboard navigation in the Search++ dialog (the main one that can be docked, not the Search in Files dialog) is clunky and not comprehensive.
There’s no straightforward way to invoke something like “Select in Marked Text” without using the mouse.
There’s a setting to focus the document after stepwise Find and Replace, but if you check that then there’s no way to do the next Find or Replace without switching back to the Search++ dialog first. The only way I can think of to manage that would be to add two more menu items, which you could assign to free keyboard shortcuts… as if anyone has any free yet memorable keyboard shortcuts. Doing repeated Find actions while being able to edit immediately in the document after a Find seems like a common task. It should be natural and fluid, but it isn’t.
I didn’t quite understand this specific point. Personally, I do not see any major difference between whether or not to enable the Focus the document after option named : stepwise Find and Replace commands ? Could you clarify this for me ?
You said :
3 For Search in Files actions, there is presently no warning about files that are open in Notepad++; the files are processed on disk. This will be more critical when Replace in Files is implemented.
My thought is to present a warning, with OK and Cancel options, noting that Search in Files only processes files on disk. Note that for Find in Files, the impact is that files that were open with changes would search based on the data on disk, not the live version of the document. Documents that are open in Notepad++ (with or without changes) and are also changed on disk by Replace in Files would show a “File changed” notification when activated in Notepad++.
Because of the way Search in Files works, it would be complicated to treat files open in Notepad++ differently, but is that something that is really important… important enough to go ahead and make the code more complicated in order to do it, so that files open in Notepad++ are processed as open documents and not as files on disk?
As I mentioned in a previous post, because of your multithreaded approach, you need to scan the files stored on disks. This is not a problem for me, as long as it’s indicated by a warning that could be dismissed until the next time Notepad++ is opened.
You said :
4 The date selection controls in the Search in Files dialog look awful in dark mode. Unfortunately, it turns out the Windows control I used is just about impossible to render in dark mode. (At least, I haven’t found a single example in open source of someone doing it successfully.) So I expect to replace it with something simpler, more like a text control with a drop-down history, where you just type the date.
Would it be useful to be able to enter the time, and not just the date, to limit which files are examined?
I do not think it’s necessary to include the time, since a specific date has already been selected : the search would then be limited to files from a given day, which doesn’t seem like an insurmountable challenge !
You finally said :
Would a single universal format (yyyy-mm-dd) be good, or is it an important user amenity to be able to enter dates in your locale format (e.g., mm-dd-yy in the US, dd-mm-yy in most other places)?
Would you miss the drop-down calendar control? Would you miss having up/down arrows (spin control) for the elements of the date and thus needing to type the numbers to change the date?
Does anybody even think the date filter is useful in the first place? Do I need a way to take a date from a specific file, rather than the user knowing what dates are wanted, to make it useful?
Technically speaking, using the universal format (**`yyyy-mm-dd**), in text mode, would certainly be easier to implement and would also ensure correct display in both modes ( light and dark ) ! Of course, a reminder of the syntax to use would be necessary !
Best Regards,
guy038
