survey: Incremental search usefulness
-
@asvc “incremental search” and “classic search” shares the same code. So in theory, it could be easy to add a “reg exp” option in the incremental search.
About mark creation, I don’t know.In an other hand, lot’s of feature are not accepted by the project owner. it would be better to have @Don-HO approval before dev otherwise it would be a waste of time.
-
@cmeriaux said in survey: Incremental search usefulness:
it could be easy
Very few things ever end up being “easy”, in software development.
I’ve not attempted dev on Notepad++ itself, but I do other software dev.
Anything that seems easy on the surface often has hard-to-overcome implications, and often in the end can’t be implemented at all (without huge risk).
But, I wish people would stop using the “E” word, even prefaced with “In theory”Here’s the first “hard” thing about it, the entire idea:
I don’t know that I like the idea of incremental search being regex-capable.
Typing regexes isn’t like typing normal text.
With normal text you pretty much know where you are going; part of the flow of typing.
In typing regex it is more of an experimental process; try something, see what matches, back it out, add something new…
If I’m using incremental search, my goal is to find something really fast, not mess around with a regex.Also, one presumes that
dot matches newline
would never be enabled for this?
As an example of why this would be bad:
Type.*
into the incremental search box and you are instantly sitting with your caret at end of file, with no great way to get back to where you started so you can do a better incremental search.
Maybe the answer is, don’t type.*
, but…I suppose one could argue, if you don’t like the regex part of this feature, don’t enable it. Presumes that the feature would have an enable/disable.
@asvc said:
Ability to create marks for the lines matching the search results
Surely there is already sufficient mechanism for this type of operation WITHOUT involving the incremental search feature.
-
@ Alan-Kilborn I’m sorry but I don’t like your tone. You can moderate your language and show a little more respect and diplomacy.
When i say “incremental search” and “classic search” shares the same code. So in theory, it could be easy to add …” it’s because I know the code behind. I didn’t said that without knowing anything behind. I’m a contributor, ok it’s only 14 commits but it’s better than nothing.
You may write less on the forum and contribute more on github -
I’m not sure what was objectionable about my language/tone/respectfulness/diplomacy in the posting above. Sure, sometimes my posts are a little “dicey” but I don’t see it this time around. :-)
I stick by my “nothing is easy” stance. I fight that perception (and the fallout from it) on a daily basis at work. Code can be shared by functionalities, but that doesn’t necessarily make anything easier; sometimes it is a burden that makes things harder. “Bound by your history” and all that…
I have built the Notepad++ source code myself, and have experimented with it a bit to see how certain things work, but I choose not to contribute any changes, because of one more thing that I’ve observed that is not “easy”: It is not easy (or even likely) to get your code changes accepted. I see you agree with that now that I reread your posting: “lot’s of feature are not accepted by the project owner”
I have seen some of your contributions and I thank you for them as they have made Notepad++ better. You are lucky that your small amount of commits have been welcomed into the codebase.
By the way, I don’t think 14 commits is “small”; more like “medium” amount. :-)BUT…
In commenting on my “tone” you seem to have ignored the rest of the content of my earlier posting; where I raise some points about possible changes to incremental search. I’d certainly be interested in what you think, as would others I’m sure.
-
Hello @cmeriaux, @alan-kilborn, @asvc and All,
Like Alan, I’m really dubious about the advantages of regular expressions in incremental search ! A simple example :
Let’s suppose you would like to highlight all occurrences of ranges of characters between the uppercase letter
I
and the closest lowercase letterw
, so the regexI.*?w
:-
First, we tick the two options
Highlight all
andMatch case
-
Pressing the
I
letter, I get###
occurrences -
Pressing the
.
char => Just1
occurrence : this regex ;-)) -
As we could search for the literal string
I.
OR for the regexI.
, we need an option that would had been previously ticked. Let’s assume it’s the case. Then :
- I => Any uppercase letter I - I. => Any uppercase letter I followed by ONE STANDARD character - I.* => Any uppercase letter I followed by ALL STANDARD characters of CURRENT line - I.*? => Any uppercase letter I followed by the SHORTEST range, possibly NULL of STANDARD chars => Letter I ONLY - I.*?w => Any uppercase letter I followed by the SHORTEST range, possibly NULL of STANDARD chars till a lowercase letter w
Seemingly, there’s no logic on such a progression ! I, personally, prefer to use the
Mark
dialog to get, at once, all occurrences of the regexI.*?w
, with the possibility of bookmarking all the lines where the different occurrences occur ;-))
Some thoughts :
-
It could be of some interest to add an option
Match whole word
to the traditionalincremental
search ! -
To easily switch between the
incremental
dialog, keeping it opened and the main text window, I, personally, use :-
The
Ctrl + Alt + I
shortcut to focus on theIncremental
dialog, again -
A double hit on the
Windows
key to focus on the main text window, again ( A work-around ! )
-
-
To close the
incremental
dialog, when focused, I simply hit theESC
key
=> Surely, easier methods for such actions could be implemented ;-))
As a conclusion, I believe that the
Incremental
search should remain rather basic, at it is in some browsers, while hitting theCtrl + F
shortcut !Best Regards,
guy038
-
-
@cmeriaux , @Alan-Kilborn , @guy038 .
It sounds like “incremental” is a bit of a point of disagreement here.
How about we replace it with the “regular search in the docked panel”?To elaborate on the usefulness of the real-time highlighting (massive time-saver!), here as a short example using the message above.
Say I want to wrangle lines that begin with the
- I.*
pattern:Instant visual feedback reaffirms correctness of the chosen regexp and allows user to adjust it on the fly.
-
The type of search demonstrated (effective screencast, BTW) does indeed seem useful as something different than the incremental search feature.
I like that it doesn’t move the caret and thus the user’s view at his data doesn’t “jump” as I mentioned before. Even if the match extends below the user’s view I think the screen should not change (too much of a lost of context)?
-
@Alan-Kilborn said in survey: Incremental search usefulness:
Even if the match extends below the user’s view I think the screen should not change
Precisely. And in the VIM world, there is a concept of “action”.
Check this out:
- Search
- Perform action on the result.
Hence I have asked this question.
-
@asvc said in survey: Incremental search usefulness:
VIM world, there is a concept of “action”.
Sure, I understand the VIM thing.
There have been requests for it before that have gone unheeded.
It’s OK…but it’s probably not a valuable thing for the vast majority of N++ users.Hence I have asked this question.
Which is probably a more “mainstream” (valuable) way of doing it for N++ users.
Let’s see if it gets implemented. -
Here is a screencast of the POC I’ve did. https://youtu.be/_s6BJf4sdw4
I’ve added controls to select the search mode:- Mode normal
- Mode extended
- Regular exp
- . matches new line (for regex)
It’s less than 100 code line. So it has good chances to be accepted by the author.
Using regexp mode is very nice, specially if you’are not the RegExp kingWould you prefer several control (like in the screen cast) or a combo box to select the search mode ? I hesitate.
-
@cmeriaux i would prefer several control by far!!!
-
So the one of us here (@guy038) that understands regex and its applicability and usefulness better than anyone else, makes a statement like:
I’m really dubious about the advantages of regular expressions in incremental search
and yet we proceed? Well…okay…
Would you prefer several control (like in the screen cast) or a combo box to select the search mode ? I hesitate.
I would vote for a dropdown.
It is easier to change with a radiobutton approach – don’t use checkboxes like in the screencast! – but since @guy038 and I and … aren’t ever going to change it away from Normal, it’s okay. :-)
It seems like the text for the modes should exactly correspond to that used on the Find screen as well – I noticed in your screencast that it does NOT correspond.
@Alex-M said:
i would prefer several control by far!!!
Can you clarify what that means? After several readings it doesn’t make sense, to me at least.
-
One more point: I thought @Ekopalypse said somewhere that if incremental search were going to be improved, he’d like to see the size of the text input box be wider, and probably scaled to the size of the main Notepad++ window. How about making that change as well?
-
Hi, @cmeriaux, @alan-kilborn, @asvc and All,
Ah, Christophe ! Your Youtube animation is really valuable ! As they say in France: “A single image is better than a long speech !”. So, when I said :
Like Alan, I’m really dubious about the advantages of regular expressions in incremental search !
Now, I won’t be so hesitant and suspicious about it ! Indeed, despite of the fact that, in regex mode, the result of search, necessarily, does not respect a logic progression, I do see, now, the great advantage of an immediate match, as mentioned by @asvc, especially for beginners and intermediate regular expression users ;-))
I certainly do not want to appear as a guru, always having the best opinion on any subject. I am not infallible and able to recognize that I was wrong and that my judgment was a hasty fear ! As always, only practice will tell us the real potential of
Incremental search
, in extended or regex mode but I think it would be really useful to include this new feature in a next release ;-))Most of a time, we’ll probably use the normal mode. But I admit that the possibility, from times to time, to run a regex or extended search is really a
+
!Best Regards,
guy038
-
@guy038 said in survey: Incremental search usefulness:
I certainly do not want to appear as a guru
Certainly no one thinks you try to be, you’re just doing the best you can.
You can’t help how others see you, up on the regex mountain. :-)Now, I won’t be so hesitant and suspicious about it
Sure, OK…now I stand alone at not seeing a great amount of value in incremental regex search.
It doesn’t bother me.Let’s see if it gets accepted.
But…how about other constructive criticism on the screencast, from someone other than myself?
-
Yeah, that’s what I’d like to have too. Very nice.
I’d rather have a combo box, and as @Alan-Kilborn said, the input field should fill the remaining space.
Another thing that is obvious but easy to forget is that each control should be created with WS_TABSTOP so I can use the TAB key to access it.@guy038 - Ein Bild sagt mehr als tausend Worte (A picture is worth a thousand words)
-
hello,
here is a new version with a dropdown list to select the mode. each string is same as the classical find dialog.
it’s much consistently that way (for the UI and the Code)
Tab stop hasn’t been forgotten ;-)
I’ve increased the width of the input field (much easier than filling the remaining space )
https://youtu.be/lnfJBeb2RkU -
@cmeriaux said in survey: Incremental search usefulness:
Here is a screencast of the POC I’ve did. https://youtu.be/_s6BJf4sdw4
Yessss. Thanks heaps.
@cmeriaux said in survey: Incremental search usefulness:
Would you prefer several control (like in the screen cast) or a combo box to select the search mode ? I hesitate.
Good question.
- Check-box: one click less to toggle mode
- Drop-down: visually cleaner and allows to preserve space for the input field
I vote for the combo-box with (ideally) assignable hotkeys. For example:
- CTRL+F – live regexp search
- CTRL+SHIFT+F – open dedicated search window
- ALT+SHIFT+F – something else.
-
I’ve increased the width of the input field
Have you opened an issue on this for github? Or maybe there is an existing one?
If one hasn’t been opened yet, with the addition of widening the input field maybe we are in the area of general improvements to incremental search, and the issue should reflect that.What I’m getting to is another general improvement that I believe @guy038 brought up: The ability to switch back to the editor window without closing the incremental search window. Currently Esc closes the incremental search window and switches back, but it is rather visually disruptive to close the window when you are probably going to use it again soon.
I’d be okay with Esc switching focus back and a different keycombo (alt+f4 ?) closing the window.
The second video has a nicer look than the first. Well done.
-
Thanks for you feedback.
Dop-down solution won.
I’ve created an Issue (https://github.com/notepad-plus-plus/notepad-plus-plus/issues/8247)
and a Pull request for the things I’ve done ( https://github.com/notepad-plus-plus/notepad-plus-plus/pull/8248 )A Nigthly build is available if you want to test or to play.
https://ci.appveyor.com/project/cmeriaux/notepad-plus-plus/builds/32773840/job/yhkoe9ieaxdmkwuf/artifactsLet’s create other issue for other demands. Let’s keep Pull Request as small as possible to increase the probability to be integrated.