survey: Incremental search usefulness

astrosofista

Good advice, thank you. Without it I would have failed to install the test build.

It looks nice :)

Alan Kilborn

@astrosofista said in survey: Incremental search usefulness:

Good advice, thank you. Without it I would have failed to install the test build.

Yes, one thing I didn’t mention that maybe I should have:
There’s a Scintilla DLL artifact there as well, but as there typically aren’t often changes made to the Scintilla part of Notepad++, the one that comes with a recent Notepad++ releases should be fine to use for tests like these.
Also, I’m not sure these Scintilla DLLs are “signed”?

cmeriaux

@Alan-Kilborn Thanks alan for all the details you gave about nightly build.
Inded the scintilla.dll ant notepad++.exe are not signed

The nightly build issue on @guy038 computer means that DonHo release Npp++ with another compiler/options than AppVeyor tools (Visual Studio 2017) which may not support windows XP.

asvc

In light of the response from @donho… What are our options?

I have downloaded AppVeyor build, replaced SciLexer.dll and notepad++.exe in the NPP directory and got this:

Restoring old SciLexer.dll fixes the issue and Notepad++ launches with the brand new Regexp powers in the quick search bar! Thanks @cmeriaux .

As I do believe we can find a way to convey viability of this feature to mr. Ho, let’s think about next steps.

Would it be possible to highlight all matches instead of the 1st one? I have tried “Highlight all” checkbox – does not work.

cmeriaux

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

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:

Maintain a fork that merges latest code with the selected patches
Persuade the key developer to accept some particularly handy pull requests
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:

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

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.