Search++: A work in progress

Coises

@guy038 said:

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.

Coises

@guy038 said:

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.

guy038

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 the Search++ dialog , before the options :

Hitting the F key runs the default Find All operation
Hitting the S key runs the default Selection operation
Hitting the M key runs the default Mark operation
Hitting the H key runs the default Show operation

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+ N shortcut to Search++ > Search... command :

If I decide to focus on active document ( by enabling the the stepwise Find and Replace option in Settings ), I just have to do a Ctrl + Shift + N shortcut in order to focus the Search++ dialog, again
If I decide to focus the Search++ dialog ( by disabling the stepwise Find and Replace option 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 + F and Alt + R shortcuts to realize a stepwise Search / Replacement
- At any time, we can switch to current document, by using a Ctrl + N shortcut, for possible modifications. And then, go back to the plugin with the Ctrl + Shift + N shortcut

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 Shift key and a click on 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

Coises

@guy038 said:

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 the Search++ dialog , before the options :

Hitting the F key runs the default Find All operation

Hitting the S key runs the default Selection operation

Hitting the M key runs the default Mark operation

Hitting the H key runs the default Show operation

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 Shift key and a click on 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.

guy038

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 Shift key while clicking a button — would be visible immediately, in future releases, just by selecting the desired option, without needing to hold down the Shift key. Does this wording make more sense to you ?

BR

guy038

Coises

@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 Shift key while clicking a button — would be visible immediately, in future releases, just by selecting the desired option, without needing to hold down the Shift key. 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.

guy038

Hi, @coises,

Yes, I suppose that a new option could be a nice solution. However, could you mention the SHIFT key 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

Coises

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 !

and later, @guy038 wrote:

I do know about using the Shift key and a click on 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.

Coises

@guy038 said:

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.

guy038

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 N lines, both before and after, with 1 to 5 max should 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 softwares with a few well-implemented features to softwares with a plethora of poorly managed features !

Best Regards,

guy038