New proposal of further enhancement of the Search and Replace dialog (S&RD) in N++ and related tools: descriptive Help and new Features explained

This is still a work in progress: more suggestions and corrections are welcome

Also this is a newer version of the old one which is at the link: #9529

First of all I would like to thank any one which reads this document and wants to partecipate to the further enhancement of this feature of N++ by advancing further improvements of it.
Secondly, cause of its nature, this text is going to be a little bit longer than my usual posts around: my apologies for that but nevertheless IMHO it worth to read it, so thank you in advance for your kind patience.
Thirdly I want to apologise for my imperfect English: I am not English and I'm aware sometimes it can sound weird due to my limited knowledge of it. So please forgive the more than probable mistakes I will do and, if you want, when it happens correct me so I can spot and correct them and improve for a better future.

Thank you all.

That said, let's start.

ACRONYMS USED IN THIS DOCUMENT

CLIOD	:	Current Living Implementation of the S&RD in N++ 
ES&RD	:	Enhanced Search and Replace Dialog box of this proposal
N++		:	Notepad++
SJ(s)	:	Search Only Job(s)
S&RD	:	Search and Replace Dialog box in general
S&RJ(s)	:	Search and Replace Job(s)
S&RT(s)	:	Search and Replace Tool(s)
SRRW	:	Search (or Find) and Replace Results Window (or Pane?) in N++

INTRODUCTION ABOUT THE ES&RD + MINOR FURTHER ENHANCEMENTS AND EDITS REQUESTED BY OTHER USERS

{IMAGE N++-Enhancement-Search-and-Replace-DlgHR-.png}

As you can see in the reference image above, the ES&RD is pretty different from the CLIOD and it is also a bit more powerful as well. Nevertheless it will keep all of its old functionalities with few little changes and some optimizations and some important additions and enhancements.
The first thing to spot is that the ES&RD is without tab pages, as I already explicated elsewhere, so it will allow the users to see all options at once, when in Advanced view, like other stand alone pro-grade S&RTs out there, set the options and execute the SJ or the S&RJ to perform without actually change tab page at all in search for the right function. So the S&RD will become more direct if this proposal will be finally accepted and implemented by N++ developers team to finally replace the CLIOD.
This new layout, together with other convenient choices, as we are going to see, will also allow some kind of powerful automation, kinda of "batch processing" or, if you will, batch S&RJs, to facilitate the achievement of even the most complex tasks, also allowing the user to repeat them over time without the need to set all steps up from scratches every time they are needed to be executed: immagine how much System Administrators, Log Analysts, Advanced Coders and txt editors will appreciate these new features.
In fact the new ES&RD, if implemented, will allow to save SJs and S&RJs with meaningful names to recall them anytime in the future: that means saving under a single name ALL the set up done by the user into the ES&RD itself so (s)he will be able to retrive a specific job with just a click on its name and in an instant set back the dialog to perform again the job previously done (and saved) and repeat it under similar circumstances, even after a long time, without no struggle.
Of course a job can be recalled, modified and saved again under the same name, updating the old setup or even with a new name to create one or more variants to adapt it to different circumstances.
It will also allow to concatenate 2 or more SJs and/or S&RJs just clicking on the checkboxes on the left into the list and on the appropriate execution button. This way will be possible to execute with just few clicks on checkboxes and on the execute button a concatenation of S&RJs, composed by multiple jobs, to perform in seconds more complex operations at once that before needed to be tediously set up from scratches EVERY TIME they were needed and performed one at a time. Of course the ES&RD will also continue to keep all those useful feature already present into the CLIOD as the chronological history of the text stings searched or replaced saved into the drop down ctrl (or combo box) on the right of the Search for and Replace with text boxes that survive at N++ close and restart process, which aren't much in the long run by the way so they can be easily retrieved if they are used much frequently.
Another thing that has to be resolved asap, is the fleshing of the dialog title when it doesn't find any match: in fact it is known that these flashings could be a real sanitary issue for certain people which have problems as epilepsy or similar illnesses: a crisis can be triggered by fast flashing events or things. So IMO it would be better to show a more visible and also informative message as a yellow bubble or balloon hint that stays slightly above the Search text box for few seconds or until the user clicks on something else: this will also improve the user experience.

There are a bunch of other things to see into the new ES&RD of this proposal, so allow me to dive a little bit more into them; sometimes I will also try to briefly explicate my view which brought me to a certain choice, hoping my English would be able to explicate the logic behind everything for the best, as well as this ambitious project would truly deserve.

LET'S EXPLORE THE NEW GUI LAYOUT

{IMAGE 0 Sections.png}

From now on I beg you to refer to the red numbers superimposed on the images for the best comprehension of the text.
Also it is possible to click on the images to zoom and see them bigger, hopping the resolution I saved them will be enough.

At a glance we can see that the ES&RD of this proposal has resizeable borders and will keep over time the last size and position set by the user, even after N++ close and restart. Into it we can distinguish two main panes, the left one and the right one, separated by the vertical splitter n° 0 that allows to resize them relatively to each other as needed. Into the first/left pane there is the section n° 1 which can be resized as well because its right side sticks to the splitter itself: so moving the splitter the section and especially the list box in it will be resized as well: this way it will allow to see long names saved into the list. The remaining sections are all collocated at the right side of the splitter.
So the ES&RD is organized into 6 main sections in total, each one grouping more or less homogeneous options. Let me introduce them all:

1. Save and Chain S&RJs (Color: pink)
2. Behaviors (Color: yellow)
3. Actions (Color: light blue)
4. Targets (Color: light green)
5. Dialog Buttons (Color: grey)
6. Transparency (Color: grey)

As you can see from the image above each of the main sections has a different color to spot at a glance what options includes in its boundaries. This is a feature that can be modified or even removed by devs, but I hope they will keep it.

I'm going to explicate as briefly as I can the logic behind each section and how the options could (presumably) interact with each other (more or less), trying to be as clear as my English allows me.
Clearly into the final implementation of this draft some thing might be different and further more optimized, even thanks to your suggestions.
If something is not clear enough, please ask: I'll try to answer as best as I can.

{IMAGE 1 Save and Chain S&RJs.png}

As introduced before, this is the section which will allow to save, recall and even concatenate previously saved SJs and/or S&RJs to allow the user to retrive and execute them with just a few mouse clicks. This section of the ES&RD is structured as follows:

1. [SRJobName | Filter]: This text box will allow to:

• type a meaningful name for the new created job, replacing the default string in it, and to save it in combination with button n° 3.
• change/update the name of the job saved into the list beneath it: a click on the item into that list will populate this text field which will show the name of the selected item/job allowing the user to change/update it in combination with button n° 4, overwriting and replacing the old name.
• type any string to use to filter the list beneath it in combination with the button n° 5. IMHO, the typed string to use as filter would have to act as it would act the "LIKE" operator in SQL, so it will be able to find and filter any match in any part of the jobs name saved into the list itself, with no fuss or struggle for the user.

2. [SRJobsList]: This GUI element, as clearly shown by the image, is of type CheckBoxListControl (a list of items with checkboxes).
   It shows the list of the previously saved jobs and allows the user to manage them with the help of the surrounding GUI elements. In particular it allows to:

• save, show and manage previously stored jobs, allowing to handle an unlimited number of items. A single job can be made by SJ options or S&RJ options as well;
• selection of one or more of its items by Ctrl+left-click on the text of the items themselves or by mouse left-click-and-drag. That kind of lists are indeed able to accept multiple selection of items: such a property has to be activated when the control behavior is being programmed.
• the list is also filterable and sortable with the collaboration of the appropriate other surrounding GUI elements as I had anticipated already and as I will better clarify when describing the buttons behavior;
• select and delete one or more items at once;
• check one or more checkboxes binded to their items by clicking on them to concatenate their execution: that means execute them one after the other seamlessly in the order they are listed into the list itself. However they don't need to be checked seamlessly in order to perform the underlying jobs, but it will be possible to check some of them and not others, accordingly with the user contingent needs: the image explicates this logic very well, as it shows in fact some checked checkboxes and others not checked.
  The list will be populated by the user when (s)he saves a new job, giving it a name and saving it with a click on the button n° 3.
  It will also be populated by data retrieved from an xml file (maybe "SRJobs.xml"?) which will allow to save on disk all the items and even sharing them in case of need with multiple computers or even different users over the Internet. Such a file will be saved into the same directory in which N++ manages other xml files.

-> Some readers might want to ask: Why the xml file format to store the relative data?
Well, the question is absolutely legit. Because of:

• General elasticity of the xml format is a huge motivation;
• It is a more or less known format which grants great and relative easy human readability and modifiability: in fact it could be easily accessed and edited correcting and even adding and deleting items "by hands" in N++ itself if needed;
• Easy to share between computers and even to send to friends or share online if needed, as already said;
• Coherence within N++ which already relies on the same file format for other things, for example macros/shortcuts, styles, etc., which use xml too and they work pretty well.

Nevertheless, csv, inf or json files would work as well.

Back to the S&RJs list...
The name will be the "unique ID" of a SJ or S&RJ, the key to access it into the xml file and retrive all its values to set the ES&RD.
The user will have the freedom to put any wished name.
The name will not have any special length limit so the user will be able to freely adopt any style (s)he wishes for naming descriptively the created jobs, so when needed a good descriptive long name, it can be given easily.
The name can be any string composed of any Unicode/UTF chars: this way it can be used any World language and even special chars into it: for instance a meaningful name for a certain user could reflect some of the content of "Search What" and "Replace With" textboxes to be as mnemonic as possibile for the user. As also known "Search What" and "Replace With" textboxes can handle even special chars: so a job name should have to work accordingly and coherently with this property to allow to be as descriptive as possible cause a user might want to put into the name itself some special chars already present in [Find What] or [Replace with] textboxes to spot at a glance, just reading its name, what exactly that item does or to be able to filter it at needs.
No duplicate names are allowed as well: as said elsewhere, the name is the unique ID of the job and it is used by the algorithm and by the user as well to recognize and track it into the xml storage file too, so at least one char must be different to distinct the new name from already saved jobs names: giving the same name of an existing item to a new job means overwriting the existing one: that will be also possible but of course a confirmation message will be shown to the user to avoid the unwillingly loss of jobs previously set and saved because accidentally overwritten by new ones.
Of course no empty/null names are allowed nor names with just space characters, which would appear to be empty/null as well.
Clicking directly just on one name of a previously saved job available into the list, will select the name itself (and it will be shown, usually, as a white text with a blue background). This action, at the same time will:

• retrive the pertinent values previously saved into the said xml file and the whole ES&RD (that means all controls: textboxes, checkboxes, option boxes, color picker, and so on) will be populated and set to these values making ready the dialog itself to perform the relative job.
• populate the [SRJobName | Filter] textbox with the job name itself in order to allow the user to:
• change the name as already mentioned above;
• duplicate the job to crate a variant of it;
  Once selected one o more jobs it will be also possible to:
• Delete a single job at a time. Also, because the list allows multiple selections it will also allow multiple deletions at once. This will work the way as will be shown in point n° 6. Deleting a job means of course deleting its name and the corresponding underlying and related nodes "codified" and stored into the xml file on disk;
• Move up or down the selection (one or more selected items as well) as will be shown in point n° 7 and n° 8. This will allow the user to change the order/priority of execution of multiple/concatenated jobs. For moving up and down the selected items, will be more than welcome even the implementation of a drag-n-drop feature for the jobs list: I'm certain it will be greatly appreciated by users especially when the list becomes long, and indeed it will for most users.

3. [SaveAsNewJob]: This button will allow to save the whole current setup of the ES&RD as a NEW job so with a new name. This also means that selecting an existing job already listed into the SRJobsList, typing a new name and clicking on this button will allow to save a duplicate of it to facilitate the creation of a variant: logically only one job/item at a time can be saved, duplicated, renamed, customized.

4. [UpdJobName]: This button will allow to change/update the name of the selected job (i.e. to give it a more meaningful or easier filterable name): it does mean that it doesn't save the current setup of the dialog but just CHANGES the NAME of an item already present into the list and stored into the relative xml updating this file accordingly, without modifying other options/properties at all, not even its position into the list (which is its execution priority in chained jobs, which is a property itself). On the list, a right-click Menu > Rename function would also work as well to populate the relative textbox or even to rename it in place (into the list), as happens with normal files and directories.

5. [FilterTgglBtn]: This toggle button will allow to enable/disable the filter of the list: it will execute as filter the string typed by the user into the [Job Name | Filter] text field;

6. [DelJob]: This button allows to delete one or more selected items from the list and from the xml file where the relative data is stored. Because it cannot be undone to prevent unwillingly lost of jobs already saved, the delete function will be of course performed after a confirmation message shown to the user. Of course if it will be possible to implement an UNDO function the confirmation message for delete operations could be omitted, but I believe this complicates too much dev things.

7. [MoveJobUp]: This button allows to move up of one position per click one or more selected items into the SRJobsList: useful to change the order of execution (or priority if you like) of the concatenated jobs;

8. [MoveJobDw]: This button allows to move down of one position per click one or more selected items into the SRJobsList: useful as well to change the order of execution (or priority if you like) of the concatenated jobs;

-> As I already said, an even better way to move one or more items around into the list would be to also implement a drag-n-drop feature in it: it will make the operation a lot easier and more agile which will allow to move one or more items from one place to another even if they are far away from the new destination point.

9. [SortTgglBtn]: I suggest to NOT implement an automatic sorting algorithm because this might unwillingly destroy the priority order given by the user; nevertheless this toggle button will allow to sort the list on demand only: this is a feature good to have that can be used when users don't care about the priority order of execution of the concatenated jobs and their priority is to have a sorted list to facilitate the individuation "on sight" of a specific item. IMHO however the optimal implementation of this button, would be to have a kind of triple-state-button with which would be possible to perform:

• Ascending sorting
• Descending sorting
• Customised sorting: it will recall the priority order of items previously decided by the user and saved into the xml file.
  For each of those possible status of this triple-state-button, the button label will change accordingly to show to the user the next sorting order available at next click. Also a short status bar message will explicate descriptively the ordering just applied on button click event.
  To save the new sorting or priority order set by the user, the ES&RD will show a confirmation message on its close event, triggered by a click on the Close or on the x button on the upper right corner of the dialog). Alternatively could be implemented another way to do that on demand, for example with a further specific button (this would be the optimal choice).

10. [BeepCkBx]: This checkbox allows to activate or deactivate the execution of a special acoustic beep to perform after completing the operations to notify the user which will receive a feedback about its ending. Maybe this feature could even be a general option valid not only for concatenated jobs but even for single ones (is it a possibility that worth to study on?).

11. [RunAllCndJobsBtn]: This button allows to run all at once the checked jobs. Notice that in this context "checked" jobs means "chained" or "concatenated" jobs, as it was intuitively understandable since the introduction.

12. [UndoBtn]: This button will allow to UNDO all at once the replacements done in targets by the concatenated S&RJs just performed by clicking the [RunAllCndJobsBtn]. The button might work in symbiosis with the backup option exposed in the next section, for instance allowing the user to automatically and immediately restore backup files done by the procedure before performing any edits to the files. Very useful especially in such cases in which files are still closed when a S&RJ has been performed. The CLIOD at the moment doesn't allow at all any UNDO feature on closed files exposing the user to unwillingly modifying files (even a lot of them!) without any possibility to recover the old content and that is risky and also weired because nowadays users expect in general to have softwares that give them a SECURE use experience allowing to get back something if mistakes are made or if the results aren't up to their expectations: so, if you will, this feature could be a kind of solution of that huge and ugly issue still present in N++ which make it unsafe to use in some occasions, specifically when targeting closed files.

{IMAGE 2 Behavior.png}

This image shows the section of the ES&RD in which it is possible to set the options of the Behavior the algorithm will follow at runtime. Some functionalities of this section aren't changed from the CLIOD so it won't be necessary to expose them deeply here because already known.

1. [Search For] or [Find what], whatever its label is: it is a multi line text box into the ES&RD. No behavior changes from the CLIOD. If the ES&RD is resized this multi line text box will resize as well so more text can be seen and easy edited into it.

2. [Enable Replace CkBx]: With this checkbox (which "shares" the label with the n. 3 GUI element) is possible to enable/disable the [Replace With] text field and so the possibility to perform Replace operations: if this checkbox is checked [Replace with] is enabled, else it is disabled and so some other elements of the ES&RD GUI which are strictly related to the Replace operations only. It will also set the [ExecuteBtn] label to the corresponding string to notify the user about the operation the algorithm is going to perform, accordingly on the settings.

3. [Replace With]: it is a multi line text box into the ES&RD. No substantial behavior changes from the CLIOD. If the ES&RD is resized this multi line text box will resize as well so more text can be seen and easy edited into it.

4. [SwapSRT]: This button swaps the content of the text field [Search For] with the content of the text field [Replace With]. This would be useful to the user for example in order to perform an inverse S&RJ (i.e. to replace back previously replaced occurrence(s) or just some of them) or just to verify if the results of S&RJs previously performed have been done as expected, or to correct some occurrences of them or the surrounding text if they don't work well together, or by just counting them and give this info to the user, etc. It is a while I asked to implement this feature which IMHO is very useful and straight forward to use instead copy and past the text twice as it is needed by the CLIOD, which is a longer and more tedious procedure especially if you have to do it with long strings and a lot of times as happens during certain tasks while editing complex code or text files (I would use it a lot and I'm sure other users as well: I really mean a lot!).

5. [Search History] and [Replace History]: these two buttons will allow to open a drop down menu like control which stores at least 25-30 items of the history (string, Reg. Expressions, etc...) previously used in the relative text boxes and will allow the user to choose an item and insert into the relative text box with just a left mouse click. The stored items will survive even after the N++ closes so they can be retrieved even over time. An other different xml file can be used to conveniently store them. Each drop down menu will also have the possibility to be cleaned up of unwanted items.

6. [Close Dialog After Finish]: This checkbox allows the user to set the automatic close of the ES&RD after finishing performing the job or all of them in case of execution of chained jobs. If the checkbox is checked the dialog will close, if the checkbox isn't checked the dialog will continue to stay opened for further input from the user. Sometimes, depending on the operation performed, the CLIOD closes automatically without the user asking for it and must be reopened to perform further tasks, loosing time: when it happens to me and I am not finished doing things with it, it is annoying to reopen it again and again and again... So IMHO this behavior needs to be decided by the user depending on the faced scenario and providing this checkbox into the ES&RD allows the user to decide what to do about that behavior.

7 and 8) [Set Direction Up/Down]: Specifies the direction to proceed performing the job: it can be forward or backward relative to the current caret position. This options group replaces all at once into the CLIOD:
A) the Find Next button
B) the twins buttons << and >> to find backward and forward;
C) the checkbox to swap the above A) and B)
D) the Backward direction checkbox
Which are clearly redundant. So this way we'll also get a more coherent GUI.

9. [Exact Match]: does what it says matching the exact match only. In the CLIOD this options is not present which is the default behaviour if nothing else is selected. I rather prefer to see it visually defined so even a new user can say what the algorithm is going to do even without have ever used the ES&RD.

10. [Whole Word]: No behavior changes from the CLIOD.

11. [Whole Sentence]: Forces the algorithm to match the whole phrase in which at least one match is found (very useful to use together with some Actions).

12. [Whole Line]: Forces the algorithm to match the whole line in which at least one match is found. Line = paragraph and it might even mean multiple sentences into the same line (also very useful to use together with some Actions).

13. [Case Sensitive]: No behavior changes from the CLIOD.

14. [Preview Matches]: This allows to activate the possibility to see just highlighted in a real time preview of the matches into the current file and visually helps the user to set better the "Search for" string; this feature is useful especially when typing a regular expression to have an instantaneous visual help about what the algorithm is going to match once actually executed.

15. [Wrap around]: No behavior changes from the CLIOD.

16. [Set Mode]: No behavior changes from the CLIOD.
    -> Notice the removal of the last checkbox option: ". matches newline" because:
    A) It was a confusing and non standard interpretation of the "." dot, as in regular expression the dot "." means "any single character except newline", so exactly the opposite;
    B) It was redundant with "\n\r" or "\n" and "\r" which really match new line and or carriage return in both win and unix based systems;
    C) It never worked in any N++ versions in which I used it, at least for me: in fact, N++ Search algorithm always worked in the exact same manner matching a single char either with that checkbox checked or not. About that I beg you to have a look to the following animated screen capture I've just made within the 758 version of N++ I'm currently using to write this proposal:

[IMAGE 2B Animated Screen Capture.png]

17. [Start]: Orders the algorithm to start the operation from the indicated point, in this case from the Start of the file.

18. [Caret]: Orders the algorithm to start the operation from the indicated point, in this case from the current Caret position.

19. [End]: Orders the algorithm to start the operation from the indicated point, in this case from the End of the file.

20. [Line]: Orders the algorithm to start the operation from the indicated point, in this case from the line number indicated into the spin box.

21. [One Occurrence at a Time]: does what it says executing the SJ or the S&RJ one by one, one occurrence at a time: each click on the execute button is one occurrence found/replaced, if any.
    This option will be available for both SJs and for S&RJs as well.

22. [All Occurrences at Once]: does what it says executing the SJ or the S&RJ on all occurrences at once performing the job from the position indicated into Start From Group towards the indicated direction and until the end/start of the file or wrapping around if the option is set, till reaching again the point indicated into Start From Group: each click on the button is a complete run across the whole document as described above. This option might leave some occurrences intact in a single run because in particular circumstances new occurrences might step out as consequence of the replace job itself, which is a welcome behavior in some circumstances.
    This option will be available for both SJs and for S&RJs to respectively find or find and replace all occurrences at once.

23. [Until no Further Matches are Found]: As the previous but performs the job cycling until no more occurrences at all are found into the whole target(s).
    This option will be available for S&RJs only: there is no reason to be available for SJs.

24. [Run max times]: in some particular circumstances the loop of the previous point might run forever if not stopped with an appropriate limiter. This spin control allows the user to set that limiter: a simple counter to limit the repetitions of the job accordingly with user needs. Of corse if no more occurrences are found the loop will stop even without reaching this upper limit. This option is activated when the previous option is bulleted, else it is disabled. The spin control would have possibile values between min 1 and max 20: at least in my experience this range of loops would be enough to cover any possible needs. Nevertheless the user has the possibility to repeat the job by clicking again the execute button if some occurrences are still there.

{IMAGE 3 Actions.png}

This image shows further Actions the user can ask the algorithm to perform on the targets.
Notice that in the way in which the following operation are studied, if implemented, will allow the user to carry out on the targeted text files a kind of operations similar to "Set Theory" (union, intersection, subset): this will enhance a lot N++ capabilities to help the user to do particular things as analyse and even extract useful informations for example from data or log files, etc.
So allow me to dive in this section to better explicate the underlying concepts.

1. [Bookmark lines with Matches]: In this options group the user has the possibility to tell the algorithm to add or remove bookmarks to/from lines where at least one match is found, and configure this feature as needed.
   If this checkbox is checked and in "Targets" are set options to process still closed files, the [Open file with Matches] checkbox will be checked automatically so files with matches will be opened during the execution of the algorithm and lines with matches will be bookmarked.

2. [Set]: with this option active, the algorithm will add a bookmark on each line in which at least one match is found.

-> Example of use of the above option to set bookmarks:

• Search for a certain string and bookmark all lines where it has found; now change the string to search and execute again to add more bookmarks: and here you have a "Union" like operation in Set Theory.

3. [Purge before each execution]: with this checkbox checked, before each execution all existing bookmarks will be deleted, resetting the situation before actually executing the new operation implicating bookmarking new lines with matches.

4. [Unset]: if a match is found and the line has a bookmark this will be removed/unset; bookmarks set on lines without matches will stay untouched unless the user has checked the [All] checkbox in which case will be unset all bookmarks with no regard to matches.

-> Example of use of the above option (continues from the example following the n° 2):

• Now put a bullet into Unset option and change again the string to search for and hit the appropriate button to execute the operation and un-bookmark only those rows where this new string has at least a match: here you have a subset of results, as in Set Theory.

5. [Highlight Matches Found]: In this options group the user has the possibility to tell the algorithm to highlight or un-highlight matches found into the target(s). This will work similarly to the n° 1.
   If this checkbox is checked and in Targets are set options to process closed files, the n° 19 [Open file with Matches] will be checked automatically so files with matches will be opened during the execution of the algorithm and then processed.

6. [Highlight]: with this option active the algorithm will highlight the match found. Of course what is highlighted depends on what is set into Behavior > Match... options group:
   A): Exact Match: Will highlight the exact match found;
   B): Whole Word: Will highlight the Whole Word in which a match has found;
   C): Whole Sentence: Will highlight the Whole Sentence in which a match has found;
   D): Whole Line: Will highlight the Whole Line in which a match has found.

7. [Purge before each Execution]: with this checkbox checked, before each execution all highlights will be cleared, resetting the situation before actually executing the new operation implicating the highlighting of new matches.

8. [Unhighlight]: If a match is found and it has been previously highlighted already, it will be cleared unless the user has checked the [All] checkbox in which case will be un-highlighted all previous highlights with no regard to matches. In case the [All] checkbox is unchecked, what is un-highlighted depends on what is set into Behavior > Match... options group:
   A): Exact Match: Will un-highlight the exact match found;
   B): Whole Word: Will un-highlight the Whole Word in which a match has found;
   C): Whole Sentence: Will un-highlight the Whole Sentence in which a match has found;
   D): Whole Line: Will un-highlight the Whole Line in which a match has found.

9. [HighlightColorSelector] This color selector will allow the user to choose the color to use for the highlight operation so in different operations will finally be possible to highlight different matches in different colors.

10. [Filter Lines]: Allows to perform a simple filter operation by hiding or showing lines in place, into the same file.
    If this checkbox is checked and in Targets are set options to process closed files, the n° 19 [Open file with Matches] will be checked automatically.

-> Note: As we know a "hide line" feature is already present in N++. But IMHO it behaves a bit weirdly: it would be better when a line is hidden if it could not be modified at all nor copied even with menu Copy command or with the Edit > Column Editor, or anything else (but unfortunately all this is weirdly possible into the CLIOD) until the user decides to show it again... Else what would be the purpose of hiding a line or a bunch of them if they continue to be editable and copyable when hidden? Clearly it is a nonsense: a good example to follow can be a spreadsheet like MS Excel in which hiding a line works as expected: it becomes not selectable, not editable, nor copyable as well, as it is supposed to. It is also needed a more explicit way to show them again once they are hidden and to hide them altogether again if needed. So in my view such a features could be put together into the menu bar as follows:

• Menu bar > View > Lines > Show hidden lines
• Menu bar > View > Lines > Hide selected lines
• Menu bar > View > Lines > Hide again previously shown lines
  Unfortunately and weirdly, AFAIK, such a complete set of menu items (except View > "Hide lines") and relative features are not present in any place into N++: so showing an hidden line (or all of them) sometimes becomes problematic and hiding them again all at once is not possibile at all: so if a user is doing a specific job with them, has to do that one by one every time: that could be tedious and sometimes even prone to errors because some lines which need to be hidden can be forgotten by mistake and left visible). This ES&RD option group might help to solve this incompleteness of N++.

11. [Hide]: hides lines with at least one match without changing the status of other lines. To hide even more lines, multiple jobs can be chained or an appropriate regular expression can be used in search textbox. This will work with the same logic of Set Theory exposed before for n° 1 and n° 5.

-> So a hidden line:
A) Cannot be copied until shown again
B) Cannot be edited until shown again
C) Cannot be targeted by by a S&RJ until shown again
D) Can be shown by the Show option or by the Purge checkbox or by the appropriate command in menu, if implemented the Note to point n° 10.
E) Can also be shown by the following SJs performed by the ES&RD

12. [Purge before each Execution]: with this checkbox checked, before each execution all lines will be shown, resetting the situation before actually executing the new operation implicating the hiding of lines with new matches.

13. [Show]: shows already hidden lines with at least one match without changing the status of other lines unless the user has checked the [All] checkbox in which case will all lines will be shown again with no regard to matches. To show even more lines, multiple jobs can be chained or an appropriate regular expression can be used in search textbox, as for [Hide]. This will also work with the same logic of Set Theory exposed before for n° 1 and n° 5.

14 [To a new file...]: In this options group the user can set the wished option to copy or move matches, if any, to a new file that will be created and populated at runtime by the algorithm. This will be able to process one or more targets as selected into the Targets section. Only one file for the whole process will be created and populated even in the case of multiple Targets.

15. [Copy]: will copy the found matches leaving intact the original. What is copied will depend, among other things, on what is set into Behavior > Match... options group:
    A): Exact Match: Will Copy the exact match found;
    B): Whole Word: Will Copy the Whole Word in which a match has found;
    C): Whole Sentence: Will Copy the Whole Sentence in which a match has found;
    D): Whole Line: Will Copy the Whole Line in which a match has found.

16. [Move]: will move the found matches deleting the original. What is Moved will depend, among other things, on what is set into Behavior > Match... options group:
    A): Exact Match: Will Move the exact match found;
    B): Whole Word: Will Move the Whole Word in which a match has found;
    C): Whole Sentence: Will Move the Whole Sentence in which a match has found;
    D): Whole Line: Will Move the Whole Line in which a match has found.

17. [Count Matches]: No changes from the CLIOD.

18. [Backup files Before Replace]: It executes a backup of the targeted files that are going to be modified by "Replace" or "Move" jobs. Especially in complex S&RJs and even more when targeting multiple files, executing a backup of files that are about to be modified (by S&RJs or by operations implicating moving parts of the text to a new file) before actually perform the editing itself, would be in fact a great security feature and sometimes a real "life saver" in order to be able to recover the previous version of the content that is going to be modified by the job itself, especially if something goes wrong during the operation and even more if files aren't opened in N++, in which case the normal "undo" feature is not available at all.

-> Some readers might want to ask: What about the file names the algorithm has to give to backup files?
Well, the question is absolutely legit and the following is my view about it. So, suppose to have a file named
"Original file name.ext"
IMHO would be good if the algorithm would follow the following naming pattern for bk files it creates:
"Original file name [BK DateAndTimeStamp].ext"
Also, the DateAndTimeStamp should be as "yyyy-mm-dd hh.mm.ss" (with 24h time and leading zeros!), for example
"Original file name [BK 2021-03-10 15.01.09].ext".
This way will be possible to:

• have more than one copy of the same file in case of need, even for restoring it manually;
• have an exact and human readable indication of the moment (date and time with a resolution of 1 second) in which the BK file was created by the algorithm;
• have the BK file(s) near the original file into the directory, so no struggle to search for it or them in case of need: when you find the original you'll find just near it all its available BKs files as well;
• have the BK files chronologically sorted even when sorted by name into the directory itself because of the suggested DateAndTimeStamp format: a very useful feature to easily spot the wished file if more backups of the same file are available;
• thanks to the BK string added to the name will be also possibile to automatically filter and distinct or esclude backup files from the original for further RJs or S&RJs or even with other S&RTs or when navigating/exploring/searching the directory with the normal tools available with the Operative System.
  I use that pattern with certain important files on my computer on daily basis and it is amazingly useful: even if you move files from a memory to another in which case even the dates given by the Operative system might change, depending on the behavior of the OS itself: but by the use of the time stamp pattern as suggested above when the algorithm will give a name to the BK files, will make absolutely clear the exact moment when they have been created even if the date given to them by the OS has been changed for whatever reason.

19. [Open file with Matches]: Opens the targeted File(s) if a match is found in it/them: a very useful automation feature of which users (me included) feel as missing in N++. Sometimes is in fact extremely useful to open automatically a bunch of files in which at least a match has been found instead doing it manually in a separate operation from SRRW or even worse one by one from windows Explorer, especially if they are hosted in different directories.

20. [Show Results Window]: It does what it says allowing the user to choose to show or not the SRRW and populate it with a clickable log of the operations made by the job(s). In the CLIOD the search results are shown automatically by the algorithm in certain situation (for example clicking on Find All... buttons) more or less without the user asking directly for it; I'm not saying that it is a bad thing: the way as it is in the CLIOD, works usually already pretty well actually, but implementing this option will give more control to the user about what (s)he wants to do about it, especially when executing chained jobs.
    In my view, the SRRW will need also the possibility to show not only SJs (as it is now) but even S&RJs so it becomes a "must have feature" and has to be implemented to give the user the possibility to have a COMPLETE log of the operations performed, with also the possibility to save it into a .log or .txt file, while at the moment the SRRW allows to copy by mouse-right-click > Copy, only found items and not even the complete log of them, with no possibility for instance to copy the type of job performed or the file names or the lines numbers in which the matches have been found: this is also a big limitation of the SRRW itself that has to be overcome sooner or later.

-> Some readers might want to ask: What could be the new SRRW layout?
Well, in my opinion, the layout itself is actually pretty good and ergonomic so it doesn't need too much changes. What it is really needed is to improve some abilities/behaviors of the SRRW itself because as it is shown by the following animation there are some lacks of functionality which are indicated by the superimposed red arrows into the last shots of the animated sequence:

{IMAGE 3B Animated Screen Capture.png}

In particular:

• it should show not only "Search" results as it is now, but even "Search and Replace" results as well;
• one more item should be added to the contextual right click menu: "Save as..." which will allow to save as a .log or .txt file the WHOLE content of the SRRW. For WHOLE content I mean:

the whole line(s) that describe(s) the performed job(s) with all the statistics data in it;
the file name(s);
the line number(s);
the hit(s).

• Also the SRRW context menu "Right click > Copy" item already existing has to behave slightly differently: it has to Copy not only the hits, as it is now, and also shown into the above image, but it has to be able to copy effectively the WHOLE content of the SRRW. So all of the following has to be copyable:

the whole line(s) that describes the performed hobs with all the statistic data in it;
the file name(s);
the line number(s);
the hit(s);

• One more thing: the title needs to be changed as well to become coherent with the new features so the current title:
  "Find result - n° NNN hits"
• will become:
  "Find / Replace results. Total hits: n° NNN".
  That's all.

Back to the Actions Section of the ES&RD...
-> Note: in general within this section, multiple Actions at once in the same job can be set by the user and performed on the same Targets. For example a job can be set to:

• Bookmark the lines with at least a match (bulleting n° 2)
• Highlight green color the match itself (bulleting n° 6) and choosing the green color from the color selector
• Show the line (if it has already hidden before) (bulleting n° 13)
• Copy the line to the new file created by the algorithm (bulleting n° 15)
• Count Matches found (and processed) (checking n° 17)
• Open files where at least a match has found (checking n° 19)

Also they can be performed together with Replace jobs.
And so on.

{IMAGE 4 Targets.png}

This image shows the section in which the user can set what target(s) the algorithm has to process, with more powerful tools than the CLIOD. There is nothing mysterious here and also some of the options are already known cause they are the same of the CLIOD and they will behave alike, with no substantial modifications. So I will be as short as I can in describing this group of options cause I'm also pretty sure they are already self explicative by themselves about how even the new ones will behave in practice, if they will be approved and implemented.

1. [Selected Text in Current file]: Allows the algorithm to target selected text in current file only. This checkbox will be active and checked automatically in case a selection is present. Also, IMHO, it would be useful to have it work everywhere eand not, as it actually is now in the CLIOD, in S&RJs and Highlight Tabs only: I don't know about other users but I really miss the possibility to perform all possible operations in selected text only, even, for instance, bookmarking rows in just the selection or highlighting matches in it, and even in column selections, etc.

2. [Whole Current File]: Allows the algorithm to target whole current file, regardless to eventual text selections.

3. [All Opened Files]: Allows the algorithm to target all opened files at once.

Some of the following options are great solution for multiple purposes, even for kinda of "code refactoring" stored in different files of the same project, workspace, or even multiple directories, etc. They are also extremely powerful but at the same time they must be used wisely and with caution because potentially harmful for a lot of files at once. Therefore it would be wise to have both the [Backup files before replace] and [Show Results Window] checkboxes automatically checked if one of them is activated to have a log of the performed operations as a "backup plan" in case something goes to far or goes wrong.

4. [Include All Sibling Files]: Allows the algorithm to include all sibling files contained in the same container directory(ies) of the current or even all opened files, depending on which option is selected: so it will be possible to apply this option to both points n° 2 and n° 3, so even to multiple files and relative siblings contained into the same directories. It will be disabled for other options.

5. [All Files in Current Project]: Allows the algorithm to target all files in current project, regardless about if they are opened in N++ or closed.

6. [All Files in Current Workspace]: Allows the algorithm to target all files in current workspace, regardless about if they are opened in N++ or closed.

7. [All Files in the Directory] Allows the algorithm to target all files into the directory selected by the user, regardless about if they are opened in N++ or closed.

8. [Selected DirectoryCmbBox]: This text field will show the target directory of the option n° 7.

9. [Choose Directory Btn]: This button allows the user to choose the target directory to put into n° 8 combo box. So nothing new here compared to the CLIOD.

10 and 11) [Set Recursion Depth]: These spin controls allow the user to set the recursion depth to a certain level of directories to scan into, in both directions up (parent directories) and/or down (subdirectories) from the current file (if are bulleted the option n° 2 (or n° 3) with the n° 4), or directory (if it is bulleted the option n° 7 and into the n° 8 there is a directory path). Each value for up and/or down levels to scan, can be set independently one from the other to grant to the user max customizability and elasticity of choice. Indicating a value of 0 will prevent the algorithm to go towards the corresponding direction (up or down). If both recursion depth spin controls are set to 0 the algorithm will scan for files the selected directory only.

12. [Include Hidden Directories]: Includes in the scan process hidden directories.

13. [Include hidden files]: Includes in the scan process hidden files.

14. [Directories Multiple Filters]: Allows the user to specify multiple filters separated by commas or semicolons to use to match directories names to dive into, starting from the one set in n° 8. If the checkbox n° 16 on its right side is checked the algorithm will interpret the content of the field as a regular expression.

15. [Files Multiple Filters]: Allows the user to specify multiple filters separated by commas or semicolons to use to match files names to process. If the checkbox n° 17 on its right side is checked the algorithm will interpret the content of the field as a regular expression.

16. [Dir. Reg. Exp.]: Allows the user to set the content of the field n° 14 to be interpreted by the algorithm as regular expression.

17. [Files Reg. Exp.]: Allows the user to set the content of the field n° 15 to be interpreted by the algorithm as regular expression.

{IMAGE 5 Dialog Buttons.png}

1. [ToggleAdvancedStandardModeTglBtn]: Shows or hides Advanced Options of the ES&RD: at the first run the ES&RD might show by default, for instance, the following compact/reduced GUI alternative:

• The Section 2 (Behaviors) and the section 5 (Dialog Buttons) only, as indicated into the following example image:

{IMAGE .Notepad++-Enhancement-Search-and-Replace-Simplified-HD.png}

Or, in alternative, can be decided for something even further more compact.

-> Some readers might want to ask: Why this toggle button?
Well, the question is absolutely legit and this choice is motivated by the need to offer to "easy to scare" users a more compact GUI to deal with.
But clicking this toggle button (s)he will be able to show all options available to perform more complex tasks. So once the user wishes to perform more advanced tasks will click on this toggle button and the complete GUI of the ES&RD with all superpowers in it will be shown. The toggle button and the ES&RD will keep its status even on N++ close and reopen events, until the user toggles it again.
(Actually another user asked for it because was afraid that a too complex dialog might scare newbies, so I've included it even if I believe the users have to see all available tools immediately (after all N++ is a Power Editor, and if the users want something simplistic they can deal with all the limits in Windows Notepad), so they can keep an eye on and get used with everything as quickly as possible and also in this way they will know the full potential of the ES&RD at first sight so they will also be somewhat intrigued and also stimulated to use them).

2. [ExecuteBtn]: It will execute the single SJ or the S&RJ as well as set into the ES&RD itself by the user or as recalled from the list [SRJobsList]. It won't execute concatenated jobs: for this there is the relative button in section n° 1 I have already talked about: this way there is no possibility for the distracted user to confuse the current job with the eventual concatenated jobs checked into the relative list.
   The label of this button will change accordingly with the "checked" property of the checkbox [Enable Replace CkBx] to notify the user about the operation that is going to be performed. About that there are two possibilities:

3. If the said checkbox is unchecked, this button label will be set to: "Search"

4. If the said checkbox is checked, this button label will be set to: "Replace"
   Its behavior will of course change accordingly.

5. [StopCloseBtn]: if any job (or chained jobs) is/are running, the label of the button changes in "Stop" and a click on it will terminate the execution itself before its natural ending. Else, if nothing is running, the label would be "Close" and a click on it of course will simply close the ES&RD. It means that won't be possible to close the ES&RD if a job is running in that moment: first it must be completed or stopped.

-> Notice that at the moment if an operation is running into the CLIOD, it locks the GUI, and doesn't accept any commands by the user until the job finishes on its own. IMHO there must be a way to stop it for at least the following reasons:

• In case the job is taking too much time
• In case the user realizes after clicking on the [ExecuteBtn] that the running job has something wrong: for example a wrong string into Replace with textbox, a wrong option set somewhere, etc...

{IMAGE 6 Transparency.png}

No changes from the CLIOD.

IN CONCLUSION

So what I tried to describe here is, more or less, the logic underlying this proposal for the ES&RD: I know it isn't perfect yet but still a work in progress. Nevertheless I believe these enhancements are greatly needed by most people, me included, so I hope it will be constructively criticized by other users which might want to present their enhancements: so more suggestions of course are welcome, as I've already said in the beginning.
I'm pretty sure the proposal will once optimized be and in the end appreciated by the most, once implemented.

Thank you for reading and commenting.

Cheers.