Search++: A work in progress
-
Hello, @coises and All,
Sorry, @coises, but I came acroos some differences of counting, in regex mode, between your two plugins
Columns++andSearch++For my tests, I used my
Total_Chars.txtfile that you can download from this location :https://drive.google.com/file/d/1DTDQdUMgC-c2Fkc-LvlQghvtwMYyoWi3/view?usp=sharing
All countings are run in regex mode with the
Match caseoption enabled
Some time ago, I made a list of all Unicode blocks of the last version
17.0. Presently, while testing theMultiReplaceplugin of @thomas-knoefel, I updated this list and took the opportunity to include the count results obtained withSearch++alongside those already provided byColumns++And I was very surprised because there are a lot of differences in the results between your two plugins
Columns++andSearch++!?Here is a non-exhaustive list of the différenes observed :
•-------------------------------•----------------------------------------------------•----------•----------• •------------•-----------•-----------• | Block range | Block name | Total | Assigned | | N++ / MRep | Columns++ | Search++ | | | | Code-Pts | Code-Pts | | Word Chrs | Word Chrs | Word Chrs | •-------------------------------•----------------------------------------------------•----------•----------• •------------•-----------•-----------• | (?=\w)[\x{0400}-\x{04FF}] | Cyrillic | 256 | 256 | | 248 ! 248 | 255 | | (?=\w)[\x{0590}-\x{05FF}] | Hebrew | 112 | 88 | | 30 ! 31 | 82 | | (?=\w)[\x{0600}-\x{06FF}] | Arabic | 256 | 256 | | 172 ! 173 | 225 | | (?=\w)[\x{0700}-\x{074F}] | Syriac | 80 | 77 | | 34 ! 34 | 62 | | (?=\w)[\x{0780}-\x{07BF}] | Thaana | 64 | 50 | | 39 ! 39 | 50 | | (?=\w)[\x{07C0}-\x{07FF}] | NKo | 64 | 62 | | 46 ! 46 | 56 | | (?=\w)[\x{0800}-\x{083F}] | Samaritan | 64 | 61 | | 0 ! 25 | 46 | | (?=\w)[\x{0840}-\x{085F}] | Mandaic | 32 | 29 | | 0 ! 25 | 28 | | (?=\w)[\x{0870}-\x{089F}] | Arabic Extended-B | 48 | 43 | | 0 ! 31 | 40 | | (?=\w)[\x{08A0}-\x{08FF}] | Arabic Extended-A | 96 | 96 | | 0 ! 42 | 95 | | (?=\w)[\x{0900}-\x{097F}] | Devanagari | 128 | 128 | | 83 ! 91 | 125 | | (?=\w)[\x{0980}-\x{09FF}] | Bengali | 128 | 96 | | 63 ! 65 | 85 | | (?=\w)[\x{0A00}-\x{0A7F}] | Gurmukhi | 128 | 80 | | 61 ! 61 | 79 | | (?=\w)[\x{0A80}-\x{0AFF}] | Gujarati | 128 | 91 | | 62 ! 63 | 89 | | (?=\w)[\x{0B00}-\x{0B7F}] | Oriya | 128 | 91 | | 63 ! 63 | 84 | | (?=\w)[\x{0B80}-\x{0BFF}] | Tamil | 128 | 72 | | 47 ! 47 | 61 | | (?=\w)[\x{0C00}-\x{0C7F}] | Telugu | 128 | 101 | | 64 ! 68 | 92 | | (?=\w)[\x{0C80}-\x{0CFF}] | Kannada | 128 | 92 | | 63 ! 68 | 91 | | (?=\w)[\x{0D00}-\x{0D7F}] | Malayalam | 128 | 118 | | 69 ! 77 | 100 | | (?=\w)[\x{0D80}-\x{0DFF}] | Sinhala | 128 | 91 | | 59 ! 69 | 90 | | (?=\w)[\x{0E00}-\x{0E7F}] | Thai | 128 | 87 | | 83 ! 67 | 83 | | (?=\w)[\x{0E80}-\x{0EFF}] | Lao | 128 | 83 | | 50 ! 66 | 83 | | (?=\w)[\x{0F00}-\x{0FFF}] | Tibetan | 256 | 211 | | 59 ! 60 | 137 | | (?=\w)[\x{1000}-\x{109F}] | Myanmar | 160 | 160 | | 94 ! 94 | 152 | | (?=\w)[\x{1200}-\x{137F}] | Ethiopic | 384 | 358 | | 326 ! 326 | 329 | | (?=\w)[\x{16A0}-\x{16FF}] | Runic | 96 | 89 | | 78 ! 83 | 86 | | (?=\w)[\x{1700}-\x{171F}] | Tagalog | 32 | 23 | | 17 ! 19 | 23 | | (?=\w)[\x{1720}-\x{173F}] | Hanunoo | 32 | 23 | | 18 ! 18 | 21 | | (?=\w)[\x{1740}-\x{175F}] | Buhid | 32 | 20 | | 18 ! 18 | 20 | | (?=\w)[\x{1760}-\x{177F}] | Tagbanwa | 32 | 18 | | 16 ! 16 | 18 | | (?=\w)[\x{1780}-\x{17FF}] | Khmer | 128 | 114 | | 64 ! 64 | 97 | | (?=\w)[\x{1800}-\x{18AF}] | Mongolian | 176 | 158 | | 140 ! 139 | 146 | | (?=\w)[\x{1900}-\x{194F}] | Limbu | 80 | 68 | | 39 ! 41 | 65 | | (?=\w)[\x{1A00}-\x{1A1F}] | Buginese | 32 | 30 | | 23 ! 23 | 28 | | (?=\w)[\x{1A20}-\x{1AAF}] | Tai Tham | 144 | 127 | | 0 ! 74 | 114 | | (?=\w)[\x{1AB0}-\x{1AFF}] | Combining Diacritical Marks Extended | 80 | 58 | | 0 ! 0 | 58 | | (?=\w)[\x{1B00}-\x{1B7F}] | Balinese | 128 | 127 | | 64 ! 65 | 96 | | (?=\w)[\x{1B80}-\x{1BBF}] | Sundanese | 64 | 64 | | 42 ! 48 | 64 | | (?=\w)[\x{1BC0}-\x{1BFF}] | Batak | 64 | 56 | | 0 ! 38 | 52 | | (?=\w)[\x{1C00}-\x{1C4F}] | Lepcha | 80 | 74 | | 49 ! 49 | 69 | | (?=\w)[\x{1CD0}-\x{1CFF}] | Vedic Extensions | 48 | 43 | | 0 ! 13 | 42 | | (?=\w)[\x{1DC0}-\x{1DFF}] | Combining Diacritical Marks Supplement | 64 | 64 | | 0 ! 0 | 64 | | (?=\w)[\x{2000}-\x{206F}] | General Punctuation | 112 | 111 | | 0 ! 0 | 5 | | (?=\w)[\x{20D0}-\x{20FF}] | Combining Diacritical Marks for Symbols | 48 | 33 | | 0 ! 0 | 33 | | (?=\w)[\x{2150}-\x{218F}] | Number Forms | 64 | 60 | | 41 ! 2 | 41 | | (?=\w)[\x{2460}-\x{24FF}] | Enclosed Alphanumerics | 160 | 160 | | 0 ! 0 | 52 | | (?=\w)[\x{2C80}-\x{2CFF}] | Coptic | 128 | 123 | | 101 ! 107 | 110 | | (?=\w)[\x{2D30}-\x{2D7F}] | Tifinagh | 80 | 59 | | 55 ! 57 | 58 | | (?=\w)[\x{2DE0}-\x{2DFF}] | Cyrillic Extended-A | 32 | 32 | | 0 ! 0 | 32 | | (?=\w)[\x{3000}-\x{303F}] | CJK Symbols and Punctuation | 64 | 64 | | 22 ! 9 | 28 | | (?=\w)[\x{3040}-\x{309F}] | Hiragana | 96 | 93 | | 89 ! 89 | 91 | | (?=\w)[\x{A640}-\x{A69F}] | Cyrillic Extended-B | 96 | 96 | | 69 ! 78 | 94 | | (?=\w)[\x{A6A0}-\x{A6FF}] | Bamum | 96 | 88 | | 0 ! 70 | 82 | | (?=\w)[\x{A800}-\x{A82F}] | Syloti Nagri | 48 | 45 | | 32 ! 32 | 41 | | (?=\w)[\x{A880}-\x{A8DF}] | Saurashtra | 96 | 82 | | 60 ! 60 | 80 | | (?=\w)[\x{A8E0}-\x{A8FF}] | Devanagari Extended | 32 | 32 | | 0 ! 9 | 28 | | (?=\w)[\x{A900}-\x{A92F}] | Kayah Li | 48 | 48 | | 38 ! 38 | 46 | | (?=\w)[\x{A930}-\x{A95F}] | Rejang | 48 | 37 | | 23 ! 23 | 36 | | (?=\w)[\x{A980}-\x{A9DF}] | Javanese | 96 | 91 | | 0 ! 58 | 76 | | (?=\w)[\x{A9E0}-\x{A9FF}] | Myanmar Extended-B | 32 | 31 | | 0 ! 30 | 31 | | (?=\w)[\x{AA00}-\x{AA5F}] | Cham | 96 | 83 | | 62 ! 62 | 79 | | (?=\w)[\x{AA60}-\x{AA7F}] | Myanmar Extended-A | 32 | 32 | | 0 ! 26 | 29 | | (?=\w)[\x{AA80}-\x{AADF}] | Tai Viet | 96 | 72 | | 0 ! 61 | 70 | | (?=\w)[\x{AAE0}-\x{AAFF}] | Meetei Mayek Extensions | 32 | 23 | | 0 ! 14 | 21 | | (?=\w)[\x{ABC0}-\x{ABFF}] | Meetei Mayek | 64 | 56 | | 0 ! 45 | 55 | | (?=\w)[\x{FB00}-\x{FB4F}] | Alphabetic Presentation Forms | 80 | 58 | | 56 ! 56 | 57 | | (?=\w)[\x{FE00}-\x{FE0F}] | Variation Selectors | 16 | 16 | | 0 ! 0 | 16 | | (?=\w)[\x{FE20}-\x{FE2F}] | Combining Half Marks | 16 | 16 | | 0 ! 0 | 16 | | (?=\w)[\x{FE30}-\x{FE4F}] | CJK Compatibility Forms | 32 | 32 | | 0 ! 0 | 5 | | (?=\w)[\x{FF00}-\x{FFEF}] | Halfwidth and Fullwidth Forms | 240 | 225 | | 172 ! 172 | 173 | •-------------------------------•----------------------------------------------------•----------•----------• •------------•-----------•-----------• | (?=\w)[\x{102E0}-\x{102FF}] | Coptic Epact Numbers | 32 | 28 | | 0 | 0 | 1 | | (?=\w)[\x{10330}-\x{1034F}] | Gothic | 32 | 27 | | 0 | 25 | 27 | | (?=\w)[\x{10350}-\x{1037F}] | Old Permic | 48 | 43 | | 0 | 38 | 43 | | (?=\w)[\x{103A0}-\x{103DF}] | Old Persian | 64 | 50 | | 0 | 44 | 49 | | (?=\w)[\x{1CF00}-\x{1CFCF}] | Znamenny Musical Notation | 208 | 185 | | 0 | 0 | 69 | | (?=\w)[\x{1D100}-\x{1D1FF}] | Musical Symbols | 256 | 233 | | 0 | 0 | 30 | | (?=\w)[\x{1D800}-\x{1DAAF}] | Sutton SignWriting | 688 | 672 | | 0 | 0 | 127 | | (?=\w)[\x{1E000}-\x{1E02F}] | Glagolitic Supplement | 48 | 38 | | 0 | 0 | 38 | | (?=\w)[\x{1E030}-\x{1E08F}] | Cyrillic Extended-D | 96 | 63 | | 0 | 62 | 63 | | (?=\w)[\x{1E100}-\x{1E14F}] | Nyiakeng Puachue Hmong | 80 | 71 | | 0 | 63 | 70 | | (?=\w)[\x{1E290}-\x{1E2BF}] | Toto | 48 | 31 | | 0 | 30 | 31 | | (?=\w)[\x{1E2C0}-\x{1E2FF}] | Wancho | 64 | 59 | | 0 | 54 | 58 | | (?=\w)[\x{1E4D0}-\x{1E4FF}] | Nag Mundari | 48 | 42 | | 0 | 38 | 42 | | (?=\w)[\x{1E5D0}-\x{1E5FF}] | Ol Onal | 48 | 44 | | 0 | 41 | 43 | | (?=\w)[\x{1E6C0}-\x{1E6FF}] | Tai Yo | 64 | 55 | | 0 | 50 | 55 | | (?=\w)[\x{1E800}-\x{1E8DF}] | Mende Kikakui | 224 | 213 | | 0 | 197 | 204 | | (?=\w)[\x{1E900}-\x{1E95F}] | Adlam | 96 | 88 | | 0 | 79 | 86 | | (?=\w)[\x{1F100}-\x{1F1FF}] | Enclosed Alphanumeric Supplement | 256 | 200 | | 0 | 0 | 78 | •-------------------------------•----------------------------------------------------•----------•----------• •------------•-----------•-----------• | (?=\w)[\x{E0100}-\x{E01EF}] | Variation Selectors Supplement | 240 | 240 | | 0 | 0 | 240 | •-------------------------------•----------------------------------------------------•----------•----------• •------------•-----------•-----------•
Notes :
-
Unlike the
Plane 0andPlane 14, the UnicodePlane 1does not include all the différences : it’s just for testing ! -
The
Plane 2andPlane 3give identical results. -
Although this post focuses on differences between your two plugins, remark that the native
Notepad++search and theMultiReplacesearch give identical results, throughout all the Unicode planes and blocks.
As promised, I’ll give you, very soon, my suggestions and preferences regarding your post !
Best Regards,
guy038
-
-
Sorry, @coises, but I came acroos some differences of counting, in regex mode, between your two plugins Columns++ and Search++
It will take me some time to test, but my guess is that the differences come from this:
-
Search++ uses the properties returned by the ICU 78.3 (Unicode 17) API directly.
-
Columns++ uses a Python script to condense information from the Unicode Character Database tables into static C++ structures which can be searched quickly at run time. Subsequent tests (I think it was you who first ran them) showed that my method does not capture all relevant Unicode properties for all characters correctly.
-
Notepad++ and MultiReplace use whatever Boost.regex does by default when matching UTF-16 or a legacy codepage. I think this relies entirely on Windows character classification routines.
I expect that the results in Search++ using Regex and ICU will be identical. Any discrepancies would probably indicate bugs in the Regex implementation; the possibility of running tests like that is why I included ICU in the first place.
Edit to add:
If you simply count word characters (\w) in your Total_Chars.txt file, you’ll see that Notepad++, Columns++ and Search++ (Regex or ICU) come up with different counts:
Notepad++ native: 48,031
Columns++: 146,443
Search++: 149,366Regex in Search++ uses the definition in Unicode Technical Standard #18: Unicode Regular Expressions. ICU in Search++ uses the ICU4C implementation of regular expressions directly.
Columns++ defines a word character as General Categories Ll, Lm, Lo, Lt, Lu and Nd plus the underscore. Relative to the Unicode standard, it misses connector punctuation (except the underscore), digits that are not decimal digits, marks, characters that are classed as alphabetic but are not letters, and the join control characters.
Notepad++ native search and MultiReplace use Boost.Regex without customization for character traits, which relies on GetStringTypeExW. I think a word character is defined as one which returns the flag for C1_ALPHA or C1_DIGIT or is an underscore.
-
-
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 30maximum, 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 5lines 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 theSearch++ resultspanel !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
-
(I’ll answer various parts of your post in separate comments.)
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 !
As above, just a warning, before the replacement, that any non-encodable character will be replaced with a ? symbol !
First, I must apologize: my original observation, to which you responded, was not as well thought out, nor as clear, as it should have been. The problem differs significantly depending on whether the search is against the current document, multiple open documents, or files on disk. This response is ridiculously long, largely because I’m “thinking out loud” what I should have thought to myself before posting the item about characters inconsistent with file encodings in the first place.
Don’t analyze files first
The thing is, I don’t know what characters cannot be encoded until I know the encoding of the document or file.
For searching an open document, it’s possible to get the encoding from Notepad++ using NPPM_GETBUFFERENCODING, but there is a problem: as best I can tell, that message doesn’t tell you when an entry from the Encoding | Character Sets menu is in effect (either because the user selected it, or because Settings | Preferences… | MISC. | Autodetect character encoding is enabled). The buffer will be in UTF-8, which means all Unicode characters would appear to be valid, but anything not in the selected character set would be lost when the file was saved.
(Somewhat mitigating this is that Notepad++ itself allows characters that can’t be encoded to be entered or pasted when a character set is selected. You can demonstrate this by opening a new document, selecting Western European | Windows-1252, pasting
Abcdefgαβγδxyz.into it, then saving and reopening. The alpha and delta are changed to a and d, the beta is changed to a German sharp s, and the gamma is replaced by a question mark. Yet no sign of this appears when you paste or when you save.)For files on disk, there is no way to determine the encoding without reading the file. Reading every file first to determine the encoding before doing a find or replace could double the time it took to do the operation; yet with Replace, doing some but not all replacements in a folder could leave the user with a very confusing situation.
The more I think about it, I believe the only way to deal with this — and other things that can go wrong — will be to have Replace in Files by default create new files, effectively keeping the original files as backups that can be restored if the user wants to “undo” the entire operation. The downside is that doing so will take more space on the target device and “pollute” the device, at least temporarily, with unwanted files; for large files with only a few small changes on random access devices, it could make the process much slower as well. So it would have to be an option.
At present, I have nothing equivalent to character sets or Autodetect character encoding in Search in Files; anything that doesn’t have a byte order mark and isn’t valid UTF-8 is assumed to use the system default code page (aka “ANSI”). That could cause trouble if people have mixed legacy encodings in files they try to search, since unlike when loading a document in Notepad++, there would be no visual indication that anything is wrong. At the very least, there is the problem of whether pure ASCII files should be assumed to be ANSI or UTF-8 if a replacement uses a non-ASCII character that is in the system default code page.
just put a warning, before the search, that any non encodable character will be changed into an ? symbol, within the Search++ results panel !
The results list is no problem; it’s always in UTF-8. For the find string, the reason for showing a warning would be to tell the user the requested search can never succeed. For single document searches, it could be helpful to show an error bubble if the find string can never match because it includes characters that cannot be represented in the current document encoding (like searching for a Greek letter gamma in an ANSI document when the system code page is Windows-1252). For multiple document searches, the completion message (e.g., “Found 12 matches in 7 of 9 open documents.” or “No matches found in 5 open documents.”) could include that some (or all) documents were skipped because the find string includes characters inconsistent with the documents’ encoding. Something similar could be added to Find in Files.
The difficult part of this is that for regular expression searches, it’s not simple (algorithmically) to tell which characters must match for the whole expression to match, and which are only required by some alternatives. It might not even be possible in the general case; I would have to investigate that.
But I don’t think it’s all that important for the find string, and it could be limited to warning about Plain text searches that can never succeed, if it is worth doing at all.
For replacing, though, it bothers me more, particularly the problem that in Replace in Files it will be dreadfully inefficient to attempt to determine the encoding of all files before starting any replacements — which suggests that notifying the user when a problem actually happens, not trying to predict it ahead of time, would be the way to go — yet, being left with a folder where some files have been processed and some could not be processed could easily be problematic.
In the end, I should not have raised this point at this time. It doesn’t have much impact in the find case (just identifying why a search has no results), while the worst case, Replace in Files, can’t really be evaluated until I actually design and implement Replace in Files. I apologize, again, for the diversion.
-
You said :
- 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 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 ?
The difference with that option is whether Find or Replace (but not Find All or Replace All) leave keyboard focus in the Search++ dialog or put it in the document.
Putting focus in the document means you can start typing, deleting or navigating, if you choose, immediately upon finding or replacing. You don’t need to click in the document or type Ctrl+N first. However, it also means that if you want to Find or Replace again, you have to use the mouse to click the button or use whatever key combination you’ve assigned to Plugins | Search++ | Search… to return focus to the dialog. You can’t just press Alt+F and/or Alt+R repeatedly, because those only apply when the Search++ dialog has focus.
What I’m saying I think is missing is something similar to F3 for Notepad++ search: the ability to leave focus in the document, instead of bouncing back and forth between the document and the dialog, and still do repeated finds (and, as I intend it, also replacements) with a keyboard combination. If you use the floating dialog rather than the docking one, being able to close the dialog and still continue searching/replacing step by step is valuable.
The earlier point was just about the general lack of key combinations for functions on the drop-down menus. Windows has the split button (button with a drop-down) as a native UI element, but while you can access the drop-down with the down arrow on the keyboard once focus is already on the button, the only way to move focus to the button without activating its main function is with the tab key; you can’t use an Alt+ combination, because that does the action on the key (and does not move the focus). So if focus were in the Find box and you wanted to perform a “Show” using only the keyboard, you would have to type Alt+M twice (moving focus to the Match case box and toggling it, then toggling it back), then Shift+Tab (tabbing backward to the Find All button without activating it), then pressing the down arrow key to open the menu and H to select Show.
That’s way too hard to do a simple thing. I tend to be sensitive to keyboard stuff because, a long time ago, I was on a beta team for some software, and also on the team was someone who was disabled in such a way that he could not use a mouse. It made me very aware that there should always be a straightforward way to do anything by keyboard only.
-
I would keep option 2 ( Accept the SHOW feature as is ) and, eventually, ask @DonHo about the hidden lines !
Yes, I think so, too. After your observation of navigation failing to work as expected after Show All, I realized much of what I thought was a problem with hidden lines may have been due entirely to my faulty implementation of Show All (which I’ve already fixed for the next release).
That leaves the main weakness being that the hidden lines status is lost when changing tabs; when you change back, Notepad++ restores what it thinks was the hidden lines status.
I think I have a solution to the other problem you observed with Show (that doing a second default Show typically doesn’t work, because it performs Show in Marked Text when you probably don’t want that). Show should use a different style (indicator) than the one used for marked text. I have most of the code needed for that working already, so a version of that will be in the next release.
-
Hi, @coises and All,
@coises, I suppose it would be worth to add, in the documentation, that, after pressing the
▼key, at the rightmost part of theSearch++dialog , before the options :-
Hitting the
Fkey runs the defaultFind Alloperation -
Hitting the
Skey runs the defaultSelectionoperation -
Hitting the
Mkey runs the defaultMarkoperation -
Hitting the
Hkey runs the defaultShowoperation
Regarding the general problem about focusing within the plugin dialog or within the current document, I don’t bother about it. Given that I attributed the
Ctrl + Shift+ Nshortcut toSearch++ > Search...command :-
If I decide to focus on active document ( by enabling the the
stepwise Find and Replaceoption in Settings ), I just have to do aCtrl + Shift + Nshortcut in order to focus theSearch++dialog, again -
If I decide to focus the
Search++dialog ( by disabling thestepwise Find and Replaceoption in Settings), I see three advantages :-
Firstly, we do not modify the current document by mistake, as focus is on plugin
-
Secondly, we can use the
Alt + FandAlt + Rshortcuts to realize a stepwiseSearch/Replacement -
At any time, we can switch to current document, by using a
Ctrl + Nshortcut, for possible modifications. And then, go back to the plugin with theCtrl + Shift + Nshortcut
-
You said, in the first of of last three consecutive pôsts :
For multiple document searches, the completion message (e.g., “Found 12 matches in 7 of 9 open documents.” or “No matches found in 5 open documents.”) could include that some (or all) documents were skipped because the find string includes characters inconsistent with the documents’ encoding. Something similar could be added to Find in Files.
I agree to add these messages which give extra inormation on the current search !
On the other hand, in your previous loooong post, you said :
3-4 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)?
And I answered :
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 , at the rightmost zone of the Search++ panel — which would clearly indicate whether we’ve selected and run : a list, a selection, a mark, or just the results of a search !
I do know about using the
Shiftkey and aclickon any drop-dwon menu. However, what is your general feeling about my reply : any operation would be clearly identified and affecting a default option would not been anymore mandatory ?!
You also said in the same post :
4 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.
And I answered :
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 !
Did you already tried to test the regex proposed in that post and did you deduce some facts ? I didn’t even think it was possible to get a correct result while seeing a message telling you that the current search is incorrect !!
Best Regards,
guy038
-
-
Thank you for all your time looking at this and processing my rambling ideas. A couple answers to this part:
I suppose it would be worth to add, in the documentation, that, after pressing the
▼key, at the rightmost part of theSearch++dialog , before the options :-
Hitting the
Fkey runs the defaultFind Alloperation -
Hitting the
Skey runs the defaultSelectionoperation -
Hitting the
Mkey runs the defaultMarkoperation -
Hitting the
Hkey runs the defaultShowoperation
Noted. I can add more details about keyboard navigation. The big problem, though, is that there is no straightforward way to navigate to that down arrow menu (or any of the other split button menus) by keyboard. And I still haven’t thought of a good way to make it work.
Regarding the general problem about focusing within the plugin dialog or within the current document, I don’t bother about it.
Good to know that what I have so far is comprehensible and working as intended. The default for Focus the document after stepwise Find and Replace commands is unchecked, which as you explain is likely to be less confusing than checked.
You said, in the first of of last three consecutive pôsts :
For multiple document searches, the completion message (e.g., “Found 12 matches in 7 of 9 open documents.” or “No matches found in 5 open documents.”) could include that some (or all) documents were skipped because the find string includes characters inconsistent with the documents’ encoding. Something similar could be added to Find in Files.
I agree to add these messages which give extra inormation on the current search !
Noted. I will probably attempt it only for Plain text searches first, as it is easier for plain text. (No need to figure out which characters it can’t match without: it needs all of them!)
On the other hand, in your previous loooong post, you said :
3-4 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)?
And I answered :
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 , at the rightmost zone of the Search++ panel — which would clearly indicate whether we’ve selected and run : a list, a selection, a mark, or just the results of a search !
I do know about using the
Shiftkey and aclickon any drop-dwon menu. However, what is your general feeling about my reply : any operation would be clearly identified and affecting a default option would not been anymore mandatory ?!I have a feeling we are not communicating on this one. I can’t quite figure out what you mean, and I suspect what I wrote didn’t convey what I intended. I’ll address this in a separate post.
You also said in the same post :
4 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.
And I answered :
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 !
Did you already tried to test the regex proposed in that post and did you deduce some facts ? I didn’t even think it was possible to get a correct result while seeing a message telling you that the current search is incorrect !!
It isn’t possible without changing Boost.regex. The code for Boost.regex is open source. What I’m considering would amount to “forking it” to change two things:
-
The complexity message occurs when a heuristic in the Boost.regex code estimates that “too much” text is being reexamined while “too little” progress is being made in moving the initial match point forward. It is important to understand that this is not testing for something like memory exhaustion which would crash the program, it’s merely making a guess as to whether the supplied regular expression is one that will never complete (or will take a ridiculously long time). I would want to remove that test entirely and let the user decide when it’s taking too long and making too little progress.
-
Boost.regex needs that because it has no means of reporting progress or canceling searching before it either finds the next match or finds that there are no more matches. So if you’re searching a large file for something that is near the end, Boost.regex doesn’t let you visualize how the search is proceeding. (The only time we see progress is as each one of multiple matches is found.) There is also no clean way to cancel a search for the next match until it either succeeds or fails. I would want to add a callback that would let the calling program monitor progress and cancel at user request.
I listed this because it’s one of my eventual goals, but I do wonder whether people care much. I haven’t tried to do it yet. My plan is to get to a “1.0” version of Search++ before I work on that. There are a couple other things that would probably involve modifying Boost.regex code (Unicode word boundaries and more complete implementation of Unicode properties) which I also am considering, but will likely not attempt until after a 1.0 version.
-
-
Hello, @coises,
Regarding this specific point :
3-4 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)?
May be I expressed my choice very badly ! Actually, I just wanted to say that the changes in the appearance of the various buttons ( Find, Count, Find All, Replace, Replace All )— which occur when you hold down the
Shiftkey while clicking a button — would be visible immediately, in future releases, just by selecting the desired option, without needing to hold down theShiftkey. Does this wording make more sense to you ?BR
guy038
-
@guy038 said:
Regarding this specific point :3-4 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)?
May be I expressed my choice very badly ! Actually, I just wanted to say that the changes in the appearance of the various buttons ( Find, Count, Find All, Replace, Replace All )— which occur when you hold down the
Shiftkey while clicking a button — would be visible immediately, in future releases, just by selecting the desired option, without needing to hold down theShiftkey. Does this wording make more sense to you ?I see. I think I follow what you’re suggesting, but I have to admit I don’t like it. I don’t think selecting a function from the drop-down should always make that the new one-click action for the button.
However… it could be an option. Enabling a setting like Buttons automatically change to last drop-down action would reverse the meaning of the Shift key, so that when you click an action in the drop-down menu it becomes the new action on the button, and you have to Shift+click if you don’t want that to happen.
Is that what you mean? Seems like a good idea. Thanks.
-
Hi, @coises,
Yes, I suppose that a new option could be a nice solution. However, could you mention the
SHIFTkey in this option : something like, for example :□ Buttons reflect last drop-down action, without SHIFT key
So :
-
If this option is enabled, a simple click would change the appearance of buttons and
Shift+ click would keep their appearance unchanged -
If this option is disabled, a
Shift+ click would change the appearance of buttons and a simple click would keep their appearance unchanged
BR
guy038
-
-
I had written:
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)?
@guy038 wrote:
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 , at the rightmost zone of the Search++ panel — which would clearly indicate whether we’ve selected and run : a list, a selection, a mark, or just the results of a search !
I do know about using the
Shiftkey and aclickon any drop-dwon menu. However, what is your general feeling about my reply : any operation would be clearly identified and affecting a default option would not been anymore mandatory ?!While I was writing this, you clarified what you meant, and I responded to that.
What I was attempting to describe is related to the problem you encountered when you did a default Show search and nothing happened. The reason was because the previous Show caused text to be marked, so when you did a new default Show, it was searching within the marked text, though you meant to search the whole document. That’s what “default scope” does: it might search selected text, it might search marked text, or it might search the whole document, depending on your settings and whether text is marked, or enough text is selected, at the time.
What bothers me is that before you click the button, it’s not obvious what the current default scope will be. Maybe you forgot you had text marked. Maybe you thought your selection was over the minimums you had set in Single selections must have at least:, but it was actually a couple characters short. You could still do what you meant to do by selecting from the drop-down menu, but you might not realize that you need to use the drop-down; then you’re left puzzled by why the results were not what you expected.
I’ve hit this trap myself, and I wrote the damn thing!
One possibility is that my “default scope” concept is just fundamentally flawed. Maybe the user should have to indicate, each time, whether the intent is to search the whole document, search in selected text or search in marked text. Yet I fear adding that many buttons, or using some fancy, non-standard divided buttons, would make an overly busy and confusing interface; while using modifier keys or having to use the drop-downs for everything but whole document searches would be clumsy and annoying. So I’m trying to think how I can give a visual cue as to what the “default scope” is before you click the button; that way, if it isn’t what you expected, you’ll know to use the drop-down instead (or change your selections or marks).
The problem then becomes, if I add a scope indicator that changes with conditions, how do I do it?
The first idea I listed was a bad one. A common indicator would be in the wrong place (that is, not where you’re looking when you go to click a button), and I was wrong about it always being the same, since the unchecked states of Allow default Select command to Select in Selection and Allow default Mark command to Mark in Marked Text exclude certain scopes from those commands only.
The second idea makes more sense: put the indicator on each button, letting it change as conditions change. The problem is, how would I distinguish that from the scope indicators that appear if you Shift+click the drop-down menu and select a command that does not use default scope (like “Find All in Whole Document”)? You wouldn’t (easily) know when you had selected a command with fixed scope and when you had a default scope command, except by noticing whether it ever changes when you select or mark text.
The third idea questions whether being able to set a non-default scope command as the one-click command for a button is worthwhile at all. If you can never do that, then there is no problem with confusing the meaning of the scope indicator on a button: it would always mean that is the current scope of the default scope command, since other commands could not be assigned as the one-click action for a button.
I don’t like any of my ideas. (For that matter, I don’t like my scope and extent icons, either. The arrows are OK, but as for the rest, I tried everything I could come up with and I still think they’re obscure, confusing, ugly and hard to read.)
So I guess I was hoping someone might come up with an idea I like better than my own. Or say something that would lead to me coming up with a better idea than the ones I’ve had so far.
-
C Coises referenced this topic on
-
Regarding the features under consideration :
You said :
- 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 !
Making sure we understand each other precisely is important here.
Implementing context is not quite as simple as it sounds, but for Find All commands that create a search results list, it is much trickier if the context can be requested after the search is complete, rather than specified before the search is performed.
I do understand that it would be handy to look at search results and then say, “Oh, I need some context. Expand this to show me two lines before and three lines after each match.” It’s a lot more complicated to implement that than to have the user specify context requirements beforehand (e.g., a setting that says, “When I search, show me two lines before and three lines after each match”) and include those lines in the search results.
I’m not saying it’s impossible; just enough more complicated that it’s worth understanding how badly it’s wanted or needed before trying to do it.
If I implement requesting context after the search, should it be for an individual match (“show me two lines before and three lines after this match”), for all matches, or are both options needed?
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 !
The next release will include something vaguely like this: the ability to “expand” visible blocks (such as those resulting from Show) by showing one additional line before and after each. This can be repeated to show more lines as desired. It doesn’t give find-grained control, but it keeps things relatively simple, and it may prove to be good enough.
-
Hello, @coises and All,
As for the two points you mentioned in your last post, I now realize that I should have given them more thought : in fact, it is, of course, much easier to agree — before conducting the search — on the number of context lines to add on either side of the lines containing the occurrence(s).
Thus, forget my initial proposition. I suppose that the context lines feature should be decided before the search ! Anyway, do as you like :
-
If you think you’ll be able to manage an AFTER search context lines feature easily enough, without leading to other problems, just go ahead !
-
If you think the BEFORE search solution would be safer and more simple, just prefer it !
As for the number of context lines needed, a general amount of
Nlines, both before and after, with1 to 5 maxshould be enough !
Now, I’d like to add a general point :
Do not worry too much about what I personally think. Other users may have different opinions. After all, the
Search++plugin is your brainchild, and you should plan its structure and improvements however you see fit !Personally, I prefer programs with a few well-implemented features to programs with a plethora of poorly managed features !
Best Regards,
guy038
-
-
Hello, @coises,
Regarding my post, I admit that the concept of a word is rather difficult to grasp. On that note, this is developed in the Martin Haspelmath’s article, published in June 2010, which highlights this point :
Follow this link https://zenodo.org/records/225844 to see the
PDFfile or use https://zenodo.org/records/225844/files/WordSegmentaionFL.pdf to download it !Here are a few excerpts of his publication : :
At end of section 5, it is said : … On such a view, the claim that all languages have words (Radford et al. 1999: 145) would be interpretable only in the weaker sense that “all languages have a unit which falls between the minimal sign and the phrase” …
And : … The basic problem remains the same: The units are defined in a language-specific way and cannot be equated across languages, and there is no reason to give special status to a unit called “word”'. …
At beginning of section, 7 : … Linguists have “no good basis for identifying words across languages” …
And in the conclusion, section 10 : … I conclude, from the arguments presented in this article, that there is “no definition of word” that can be applied to any language and that would yield consistent results that are in accord with our writing habits.
Thus, let’s accept that our different regex engines give us an approximate count of the
Wordscharacters set !
Note that, on the contrary, the definition of Non-space characters is quite strict, since the
Spacecharacters set, that delimit them, consist of only25Unicode characters !BR
guy038
-
This post is deleted! -
Hello, @coises and All,
Presently, I think we can summarize how your plugin works, using the table, below, on its left part :
•=========================•=======================•============================================• •===============•============================== | Actions | Scopes | Extents | | Actions | Default configuration •=========================•=======================•============================================• •===============•============================== | | | | | | | Count | In Selection | N/A | | Find | | ¯¯¯¯¯ | | | | | | •-----------------------•--------------------------------------------• •---------------•------------------------------ | | | | | | | Find All | | Before Caret | | Count | | ¯¯¯¯¯¯¯¯ | | | | | | | In Marked Test | After Caret | •---------------•------------------------------ | | | | | | | Mark | | Everywhere | | Find All | | | | | | | | | In Whole Document | In All Opened Documents | •---------------•------------------------------ | | | | | | | Replace All | | In All Opened Documents of Current View | | Select | | ¯¯¯¯¯¯¯¯¯¯¯ | | | | | •-------------------------•-----------------------•--------------------------------------------• •---------------•------------------------------ | | | | | | | | In Selection | N/A | | Mark | | | | | | | | Select •-----------------------•--------------------------------------------• •---------------•------------------------------ | | | | | | | | In Marked Text | Before Caret | | Show | | | | | | | | | | After Caret | •---------------•------------------------------ | Show | | | | | | | In Whole Document | Everywhere | | Replace | | | | | | | •-------------------------•-----------------------•--------------------------------------------• •---------------•------------------------------ | | | | | | | Find | In Selection | | | Replace All | | ¯¯¯¯ | | Backward ( if Plain text ) | | | | | In Marked Text | | •===============•============================== | | | | | Replace | In Whole Document | Forward | | ¯¯¯¯¯¯¯ | | | •=========================•=======================•============================================•The underlined actions are those which have a button, by default
Personally, your concept of a default scope bothers me a little, because it’s hard for me to know, in advance, which actions will be automatically selected by the plugin !
So, I was thinking about a radically different layout :
-
You entirely suppress the
default scopefunctionality. However, I suppose this will affect the Selection section in the settings ! -
You does not show any symbol on all the buttons, nor use any
drop-downlist -
You just show six one-letter buttons and two one-letter button for the replace actions, as below :
|F| |C| |A| |S| |M| |H| : Find Count find All Select Mark sHow |R| |A| Replace replace All-
All these simple-design buttons would open a common dialog box, in which the selected action — one of the eight possible options — would be already selected by default. This dialogue could be based on the table shown above !
-
Then, you’ll just have to check your present
scopeandextentchoices for the chosen action -
Optionally a message, summarizing everything that has just been selected, could be displayed
-
Then, this new dialog would end with three buttons :
-
A
Definebutton to attribute a default configuration ( scope and extent ) for the chosen action, without any execution. -
A
Runbutton to start the chosen action, without any default configuration to apply to -
And, of course, a
Cancelbutton, or an hit on theESCkey, to dismiss the chosen action
-
IMPORTANT :
As we must distinguish a default configuration ( the set of the
3elements : action, scope and extent ) from the execution of a simple action with ramdom scope and extent, theDefinebutton, introduced above, must record that default configuration, within this dialog.So, when clicking on the
Definebutton, the default configuration, to write in this new dialog, would be :For the
Count,Find All,MarkandReplace Allactions, one of these11messagesCount / Find All / Mark / Replace All in Selection Count / Find All / Mark / Replace All in Marked text Count / Find All / Mark / Replace All Before in Marked text Count / Find All / Mark / Replace All After in Marked text Count / Find All / Mark / Replace All in Marked Text in Open Documents Count / Find All / Mark / Replace All in Marked Text in Documents in this View Count / Find All / Mark / Replace All in Whole Document Count / Find All / Mark / Replace All Before in Whole Document Count / Find All / Mark / Replace All After in Whole Document Count / Find All / Mark / Replace All in Open Documents Count / Find All / Mark / Replace All in Documents in this ViewFor the
SelectandShowactions, one of these7messages :Select / Show in Selection Select / Show in Marked text Select / Show Before in Marked text Select / Show After in Marked text Select / Show in Whole Document Select / Show Before in Whole Document Select / Show After in Whole DocumentFor the
FindandReplaceactions, one of these6messages :Find / Replace Forward in Selection Find / Replace Forward in Marked Text Find / Replace Forward in Whole Document Find / Replace Backward in Selection Find / Replace Backward in Marked Text Find / Replace Backward in Whole Document
Notes :
-
Of course, you could, in one go, click first on the
Definebutton, then click on theRunbutton -
A simple click on any of these eight buttons, would allow to quickly verify their default configurations, as long as you press the
Cancelbutton, right after !
In other words, no more drop-down menus ! Instead, a new configuration dialog to confirm the default scope and extent values of the chosen action AND / OR the execution of the chosen action, with the present options checked in the scope and extent sections
There are surely some drawbacks to my proposal ! Anyway, what’s your feeling about this radical change ?
Best Regards,
guy038
-
-
Personally, your concept of a default scope bothers me a little, because it’s hard for me to know, in advance, which actions will be automatically selected by the plugin !
(It occurs to me that perhaps I should call it “adaptive” rather than “default” scope. Within the program code I called it “Smart,” but by the time I got the help and UI together I decided that word sounded too pretentious.)
The uncertainty about what action a button will perform bothers me, too. I’m still trying to think of a way to mitigate that. I think the idea of an adaptive scope is useful, but I don’t like that you can’t confirm what actual command a button with adaptive (default) scope will perform at a glance, before clicking it.
- You just show six one-letter buttons and two one-letter button for the replace actions, as below :
|F| |C| |A| |S| |M| |H| : Find Count find All Select Mark sHow |R| |A| Replace replace All-
All these simple-design buttons would open a common dialog box, in which the selected action — one of the eight possible options — would be already selected by default. This dialogue could be based on the table shown above !
-
Then, you’ll just have to check your present
scopeandextentchoices for the chosen action -
Optionally a message, summarizing everything that has just been selected, could be displayed
-
Then, this new dialog would end with three buttons :
-
A
Definebutton to attribute a default configuration ( scope and extent ) for the chosen action, without any execution. -
A
Runbutton to start the chosen action, without any default configuration to apply to -
And, of course, a
Cancelbutton, or an hit on theESCkey, to dismiss the chosen action
-
In other words, no more drop-down menus ! Instead, a new configuration dialog to confirm the default scope and extent values of the chosen action AND / OR the execution of the chosen action, with the present options checked in the scope and extent sections
There are surely some drawbacks to my proposal ! Anyway, what’s your feeling about this radical change ?
At first I thought you meant every single action would require clicking a button, looking at a dialog to verify the options are what you want, then clicking a button in the dialog to actually do the action. What is now Find, Find, Find would become F, dialog opens, check defaults (change them if wrong and Define), Run, F, dialog opens, Run, F, dialog opens, Run. That would be way too much interruption of flow for a user doing simple things.
- Of course, you could, in one go, click first on the Define button, then click on the Run button
Since this implies that Define does not close the dialog, perhaps you also intend that Run does not close the dialog. That would allow for repetitive actions, at the expense of having this dialog (in addition to the main Search++ dialog) on the screen while doing them, and having to click another button to close it after the last or only action.
I’m sorry, but it sounds to me as if it would be very clumsy to use. Dialogs are even more of an interruption than menus. It would also defeat the purpose of a docking dialog if another dialog has to be raised to actually do anything… unless it is also docking…
In my opinion, the main buttons must do something that’s usually useful with a single click. To what degree that should be “adaptive” (e.g., in selection when there is a “large enough” selection) is debatable: adaptation increases the chance that you can do what you want with a single click, but also increases the chance that what a single click does won’t be what you expected.
I think six buttons under the find box would be too busy, making it harder for the user to immediately identify and click the desired button. A busy layout doesn’t bother me as much with something like the Settings dialog (which, I admit, is horrible) that you don’t open often, but for something that’s meant to be used frequently, maybe even kept open in a docking panel, visual simplicity is important.
For what it’s worth, you can get some aspects of your idea now. Just use Shift+click on each drop-down menu to choose a command that does not use default scope as the command for the button. Click the button when you want to Run what you already have set. If you want to Run a different command, select it from the drop-down. If you want to Define and Run a different command, Shift+click it in the drop-down. (There is no equivalent to Define without Run.)
Additionally, in the Settings dialog you can uncheck Default commands automatically search within selections. and Default commands automatically search within marked text. to disable the adaptive mechanism, so that default scope is always Whole Document and even if you select a plain command (Find, Count, etc.) Search++ will never infer anything other than Whole Document.
-
Hello, @coises,
Preamble :
What prompted me to suggest another solution is that you seemed really frustrated with how your plugin works, since you said, among other things :
What bothers me is that before you click the button, it’s not obvious what the current default scope will be
and also :
I don’t like any of my ideas. (For that matter, I don’t like my scope and extent icons, either. The arrows are OK, but as for the rest, I tried everything I could come up with and I still think they’re obscure, confusing, ugly and hard to read.)
Even though I’ve been using Notepad++ for at least
15years, I’m just a former retired technician with some knowledge of Unix and Microsoft QBasic. So, if I took the liberty of suggesting another solution, it was solely because of your own dissatisfaction !Otherwise, I wouldn’t have written this post, since you’re surely better equipped to figure out how to improve your
Search++plugin !
That said, I’ll try to address some of your points. You said :
Dialogs are even more of an interruption than menus. It would also defeat the purpose of a docking dialog
Now that I think about it, I actually agree with you ! And, indeed, I forgot to consider the Docking dialog !
Now, regarding the mandatory buttons in this new dialog, we could, of course, add a
Define and Runbutton.Then, any of the four buttons
Define,Run,Define and RunandCancelwould close that new dialog and run the chosen action if you have clicked on theRunor on theDefine and Runbutton
Anyway, as you said, menus seem preferable. However, I still think that a layout with the six buttons Find, Count, Find All, Select, Mark and Show could be easier to use ( Personally, I’m ready to test a forked version, if you think it’s worth it )
This would simplify the number of menus :
-
The
Find,Count, andReplace Allmenus would stay unchanged -
I would suppress the last
Do not jump to next matchoption, in theReplacemenu as well as its sub-menu. To my mind, it’s rather a global way of searching which can be previously chosen in theToolsdialog with theJump to next match after Replaceoption (Ctrl + J)
Thus, a click on the
Replacebutton would just show this menu :------------------------------------------- Replace Replace backward ------------------------------------------- Replace in Selection Replace in Marked Text Replace in Whole Document ------------------------------------------- Replace Backward in Selection Replace Backward in Marked Text Replace Backward in Whole Documen -------------------------------------------- A click on the new
Find Allbutton would only show this menu :
------------------------------------------- Find All Find All in Open Documents Find All in Documents in this View ------------------------------------------- Find All in Selection ------------------------------------------- Find All in Marked Text Find All Before in Marked Text Find All After in Marked Text Find All in Marked Text in Open Documents Find All in Marked Text in this View ------------------------------------------- Find All in Whole Document Find All Before in Whole Document Find All After in Whole Document -------------------------------------------- A click on the
Markbutton would show this menu :
------------------------------------------- Mark Mark in Open Documents Mark in Documents in this View ------------------------------------------- Mark in Selection ------------------------------------------- Mark in Marked Text Mark Before in Marked Text Mark After in Marked Text Mark in Marked Text in Open Documents Mark in Marked Text in this View ------------------------------------------- Mark in Whole Document Mark Before in Whole Document Mark After in Whole Document -------------------------------------------- A click on the
Selectbutton would show this menu :
------------------------------------------- Select ------------------------------------------- Select in Selection ------------------------------------------- Select in Marked text Select Before in Marked text Select After in Marked text ------------------------------------------- Select in Whole Document Select Before in Whole Document Select After in Whole Document -------------------------------------------- A click on the
Showbutton would show this menu :
------------------------------------------- Show ------------------------------------------- Show in Selection ------------------------------------------- Show in Marked Text Show Before in Marked Text Show After in Marked Text ------------------------------------------- Show in Whole Document Show Before in Whole Document Show After in Whole Document -------------------------------------------
You said, at the end of your post :
Additionally, in the Settings dialog you can uncheck Default commands automatically search within selections. and Default commands automatically search within marked text. to disable the adaptive mechanism, so that default scope is always Whole Document and even if you select a plain command (Find, Count, etc.) Search++ will never infer anything other than Whole Document.
But, even though I unckecked, both, the
Default commands automatically search within selectionsand theDefault commands automatically search within marked textoptions and valid the new settings with theOKbutton, after selected some text containing ONLY one occurrence of the search, theCount in Selectionstill give1match only and not the totality of the matches of the current fileThen, using the
Add Selection to Marked Textoption to mark all the selection raange (Ctrl + M), again, theCount in Marked Textreturns1match, instead of the totality of the matches. Is this expected or a bug as the scope should beWhole Document?Best Regards,
guy038
-
-
Search++ version 0.7 is available:
-
Use different styles for Mark and Show. This helps keep Mark and Show cleanly separated, and it makes Always hide all lines and remove Show style from text before Show command behave more as one would expect with the default scope Show command, without introducing an inconsistency with the way other default scope commands behave.
-
Add several commands to the Tools menu, including support for the new Show style and more ability to manipulate Marked text. Some shortcuts have changed: most underlined menu characters and associated shortcut keys now match.
-
Expand visible on the Tools menu gives a rudimentary ability to show context for matches when using the Show command. Each expand visible action adds a line to the beginning and end of each visible block of text.
-
Add Find, Replace and Show tools to the main plugin menu. These commands are not very useful from the menu itself, but adding them makes it possible to set Notepad++ keyboard shortcuts for them.
-
Correct a fault in Show All Lines from the Tools menu that caused unexpected scrolling behavior. Improve the logic for vertical positioning when using Show All Lines.
Comments, criticisms, bug reports and questions as to what the hell I could have been thinking are, as always, most welcome.
The biggest change in this release is making Show more useful. Since Show no longer “marks” text but uses a different style to highlight matches, I expect the two concepts to interfere less. Show now uses a second indicator (matched to the color of the selected show style) so that it can, with some limitations, show zero length matches.
Previously, the setting Always hide all lines and remove Show style from text before Show command did what it was designed to do, but the design wasn’t very good, because leftover marks from a previous Show still affected the scope of a subsequent default Show command. Separating the mark and show styles fixes that, so the setting now causes Show commands to clear the results of any previous show, as one would expect.
Another thing that inhibited the use of Show was that you had to use both Remove marks from active document and Show all lines from the Tools menu to clear the results of a Show, and Show all lines had an annoying bug that screwed up vertical positioning after you used it. That bug is fixed, and a new command, Clear show (show all and clear style), resets the effect of Show all at once.
I expanded the Tools menu with several new commands; how useful they all are can only be discovered from experience.
The new Expand visible command on the Tools menu works with Show to make it possible to see a list of matches with some context: each time you click Expand visible (or use the Ctrl+P shortcut) each block of visible text is expanded to include the line before it and the line after it.
The addition of Find and Replace on the main plugin menu makes it possible to set shortcuts for the stepwise search commands. If you don’t typically use Alt+F and Alt+R to access the File and Run menus in Notepad++, you might try assigning those as shortcuts for Search++ Find and Replace and checking Settings | Focus the document after stepwise Find or Replace commands. The result is that you can use Alt+F or Alt+R to begin a search, have keyboard focus go immediately to the document, then continue to use the same key combinations to move through matches in the document. (This is somewhat like the behavior of F3 in Notepad++.)
-
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login