survey: Incremental search usefulness

[asvc]

@cmeriaux said in survey: Incremental search usefulness:

inded @donho refused the feature, I’m very disappointed

Do you know him in person? You are both in France, maybe a glass of coffee could iron out wrinkles of communication…After the pandemic is over.

Now, on the more serious note, the application is a shining beacon of Open-Source movement: GPLv2 license, open development model, transparency, etc.

Question is, what to do when the respected key developer and project owner is in a disagreement with users? Options:

1. Maintain a fork that merges latest code with the selected patches
2. Persuade the key developer to accept some particularly handy pull requests
3. Make change a plugin which can be released independently

As we have evidence that pull request is at very least “mergeable”, I think #2 must not be disregarded as the least destructive and one that has highest chances to survive in a long term.

Do we have a messenger here who is in touch with mr.Ho and supportive of the feature discussed?

[cmeriaux]

@asvc unfortunately I don’t know him personally. A glass or coffee could help especially we are close to Paris. ;-)

@asvc said in survey: Incremental search usefulness:

Now, on the more serious note, the application is a shining beacon of Open-Source movement: GPLv2 license, open development model, transparency, etc.

Every thing is transparency but decisions of which feature is useful should be taken by several people instead only one (which is more a dictatorship). It should be something like marketing decision oriented toward user.

@asvc said in survey: Incremental search usefulness:

Question is, what to do when the respected key developer and project owner is in a disagreement with users? Options:

Good question. Answer 2 is indeed the better one but I do not know any messenger.

[cmeriaux]

@sasumner may be a precious help cause he have a higher clearance level on Github.
hello @sasumner we are several people who wants to use a Regexp in the incremental find bar, but it has been literally refused by donho. would you have an opinion on this topic, and would you help us ?
Thanks

[asvc]

Roger that, @cmeriaux . Would it take much of an effort to highlight all matches during regexp search?

I am willing to make a short & nice screencast that presents the feature and link it to the GitHub ticket with clear presentation.
Having all matches highlighted will add some good visual oomph.

[cmeriaux]

@asvc There is a defect when the regexp contains ‘.’ otherwise highlight all works fine.
Could you do a sexy screencast without ‘.’ (\w \s \d + … )?

[asvc]

@cmeriaux said in survey: Incremental search usefulness:

Could you do a sexy screencast without ‘.’ (\w \s \d + … )?

Sure can. It’s past midnight here, added to the TODO list for tomorrow.

[asvc]

Just wanted to update @cmeriaux that it is still in the TODO list and I will post an update as soon as it is ready. Should be done by EOD Sunday.

[cmeriaux]

@asvc once you’ve done a nice screencast, I suggest you to create a feature request on github. The author wants a feature request to ve created by other user than me, to be convinced that the feature is really necessary.

Do you have an Github account ? https://github.com/notepad-plus-plus/notepad-plus-plus/issues/new/choose
Thanks

[cmeriaux]

ps: for the record there was a big debate with the author on this page https://github.com/notepad-plus-plus/notepad-plus-plus/issues/8247 . It seems to be closed . Sorry guys I’m tired trying to convince mr Ho.

[Ekopalypse]

@cmeriaux

I’m tired trying to convince mr Ho.

Thx for trying and spending the time creating the code, issue and PR.
It’s a pity that it isn’t considered to be a useful enhancement.

[Alan Kilborn]

@Alan-Kilborn said:

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 tried this in Visual Studio 2019.
I noticed that .* will only match data out to the end of the current line.
Thus it doesn’t appear to have a . matches newline capability.
Also, I couldn’t get any regex string to cause a “jump” of the viewport when a match starts on the current viewport but logically extends to higher document positions.
My original concern stems from N++'s search behavior of wanting to put the caret end of a selection at the higher document position and then making sure the caret is shown to the user.
Hopefully this is understandable.
Anyway, I like the way VS19 works in this regard, and if it ever gets accepted for N++, I hope it would work similarly.
Still not a huge fan myself of regexing this, but if it is the “will of the people” I’d go along. :-)

[Alan Kilborn]

@Alan-Kilborn said:

Thus it doesn’t appear to have a . matches newline capability.

Hmmm, I may have to retract that. Or at least qualify it, because the way it works I don’t think one can tell exactly what it is matching. It could be matching each line individually, or have one match. I think the visual highlighting would be the same either way. (Again, I’m talking about VS2019 behavior, not N++).

[Alan Kilborn]

A POSTING related to the current thread that somehow hasn’t been mentioned to this point.

[astrosofista]

@Alan-Kilborn

I seem to have missed those messages, I’m answering right now. Sorry about that.

[asvc]

I have created feature request at GitHub — https://github.com/notepad-plus-plus/notepad-plus-plus/issues/8278

@cmeriaux , I have experienced a few bugs, not sure if these are unique to my configuration yet:

1. Using “Highlight All” makes N++ scroll the viewer despite that valid match is already present on the screen:

   

2. Not all matches are highlighted. Testing on the following snippet:

   {
   	"guid": "{xx-xx-xx-xx}",
   	"name": "Command Prompt",
   	"commandline": "cmd.exe",
   	"icon": "ms-appx:///ProfileIcons/{xx-xx-xx-xx}.png",
   	// "colorScheme": "Campbell",
   	"antialiasingMode": "cleartype",
   	"closeOnExit": "graceful",
   	"cursorShape": "bar",
   	"fontFace": "Consolas",
   	"fontSize": 10,
   	"hidden": false,
   	"historySize": 9001,
   	"padding": "8, 8, 8, 8",
   	"snapOnInput": true,
   	"startingDirectory": "%USERPROFILE%",
   	"useAcrylic": false
   }
   

   Only the first one is highlighted and only two matches are highlighted after pressing “Enter”:
   

Will continue using this build and report back if more bugs are found.

[cmeriaux]

@asvc Thanks for the futur request.
The regexp issue may be related to the one already opened on github tracker

[asvc]

@cmeriaux said in survey: Incremental search usefulness:

The regexp issue may be related to the one already opened on github tracker

Which one? I might have missed the link.

[favdish]

@cmeriaux said in survey: Incremental search usefulness:

here is a survey about the “incremental search” usefulness.
Do you use it ?
Yes.

Do you need regular expression support ?
In general, yes of course. I would not even consider using a text editor w/o regex support. However, specifically in incremental search, no.

Do you need an incremental mode in the find panel ?
Do you need an incremental mode in the replace panel ?
Do you need an incremental mode in the mark panel ?
No.

[cmeriaux]

@asvc
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/3640
https://github.com/notepad-plus-plus/notepad-plus-plus/pull/8269

[Michael Vincent]

Not to beat a dead horse, but this is related to incremental search.

When I use incremental search and tick both “Highlight all” and “Match case”, do my search then close Notepad++. Upon re-open, they are not ticked anymore. Seems incremental search options are not saved in config.xml the way regular Find panel options are.

I think that would be nice improvement to incremental search that wouldn’t ruffle too many feathers?

Cheers.