@Coises said in "Whole Word Only" Option in Combination with Non-Alphanumeric Characters:

that modifying Scintilla would be “off limits” for the Notepad++ project

It mostly is.
But I think in some areas it was judged to be something that “had to be done”.

@Alan-Kilborn said in Intercept a command before it is executed:

I’m sure you didn’t know ahead of time

Read it, forgot about it :-( and then remembered it again when I read your question :-)

You can use WingetUI
9afa65b2-3420-4133-a5f0-bea9be1e1836-image.png

@alphaone

I Tried Your Solution of Find Regax It’s Working But when i tried to Replace its’s not working

It appears you did a Find All in Current Document. For this search to find hits it doesn’t matter what the current caret position is.

When you tried replace, your caret was further down in the file and no hits occurred between the position of the caret and the file’s end (the error message told you this: no occurrence was found from caret to end-of-file).

Solution for replace: Either move the caret to the top of the file (Ctrl+Home), or checkmark the Wrap around checkbox, before pressing Replace.

@astrohart343 said in Keeping the find/replace window centered on the main window:

There are moments when Notepad++ is on one monitor, and then, when I call up the dialog box, it appears on my other monitor.

At that moment, hit the shortcut for the dialog a second time, and it will re-center in the Notepad++ application’s monitor. (So Ctrl+F, Ctrl+F for FIND, Ctrl+H, Ctrl+H for REPLACE, Ctrl+Shift+F, Ctrl+Shift+F for FIND-IN-FILES, etc)

That “call it a second time” feature was added as the response to the last request that was similar to yours, and it was deemed as the appropriate solution to that and all similar problems (including yours).

It appears to me at the moment […], that the dialog box remembers its previous position.

Yes, from the way I understand it, either Windows or the app (I am not sure which, I’ve never looked into it) the position of all such dialogs, and unless the application intentionally overrides the position, the dialog will be opened in the previous location. But when the previous feature request came, he implemented the second-call-re-centers feature to override (and update) the remembered position to be centered on the current app monitor.

Another UI/UX enhancement would be to use the dialog box as a docking pane instead.

I don’t remember ever seeing an official feature request to make the find/replace dialog dockable. Like the UDL dialog, I think that dialog is too big to be effectively docked on all but the hugest of monitors… but if you think it would work for you, you could request it by following the instructions in our feature request FAQ.

I said in Columns++ version 1.1:

There is a serious fault in my progress dialogs.
[…]
What I discovered today is that the progress dialogs themselves cause the operation to take many times longer

This is fixed in Columns++ v1.1.2.

I’m still seeing misbehavior when the same file is visible in both views, elastic tabstops is enabled for the file, there is a rectangular selection in one view, and you make edits in the other view (e.g., that enlarge a column to the left of the selection). It might be that this is like the old joke — “Doctor, it hurts when I do this!” / “Well… don’t do that!” — but I’m not sure what is happening. It looks, superficially, as if perhaps the selection remains correct but the display is wrong… then, after sufficient scrolling about, it rights itself. Very strange.

So I guess the bottom line is, another update to the 1.1.* sequence that is not yet marked as stable, and quite possibly not the last before things settle down.

@Mark-Olson said in how to call the API to rename a new tab?:

calling NPPM_INTERNAL_SETFILENAME does not automatically trigger the NPPN_FILEBEFFORERENAME and NPPN_FILERENAMED notifications,

I can’t think of any circumstance where I’d care about this. But, I suppose it could be important to others…

@PeterJones
I managed to chat with him on Twitter, and got these answers:

He did not continue with the ViSimulator because:
a. He switched laptop and not using Windows at that time.
b. Lost the code because lost his git account.

He is using Windows again due to needing the MS Office and other tools, and He mentioned that he will try to find a long holiday to rewrite the plugin as per my current request:)

@Zhixun-Qu USE SendDlgItemMessage OK.

@Alan-Kilborn Thanks.solved。

@Ekopalypse done!

@glandon OK, please forgive my ignorance

LRESULT bufID = ::SendMessage(g_nppData._nppHandle, NPPM_GETCURRENTBUFFERID, 0, 0);

Hello, @robin-ramy, @ekopalypse, @alan-kilborn, @michael-vincent and All,

@michael-vincent, I tried your very fresh new release v2.2.1.1 of your plugin, on my two laptops :

An old 32 bits XP machine

A 64 bits Windows 10 machine

Regarding the XP machine, it seems to not work anymore ! I suppose that this is an expected dehaviour as XP is quite out of date !

I don’t mind to stay with the previous 2.1.2.1 release on my old laptop.

BTW, this previous version seems to work even if I check the Use DirectWrite option. But, I suppose that it’s just because, globally, the DirectWrite technology does not work properly with Win XP ?

Now, regarding the W10 64 bits machine, no trouble at all ! However, I noticed some oddities about the coloring !

Note that these oddities are identical on both 32 and 64 versions of your plugin, for the two releases 2.1.2.1 and 2.2.1.1

As a reminder, the coloring is visible ONLY IF a document is opened with one of these four languages :

CSS

HTML

JavaScript

XML

So, @michael-vincent :

Insert this text below in a new tab •-------------------------------------------•---------------------------------------------•--------------------• | | W10 64 bits machine | XP 32 bits machine | | •---------------------------------------------•--------------------• | | N++ 8.6.5 64 bits / 32 bits | N++ 7.9.2 32 bits | | •---------------------------------------------•--------------------• | | Version 2.1.2.1 / 2.2.1.1 32 / 64 bits | 2.1.2.1 32 bits | •-------------------------------------------•---------------------------------------------•--------------------• | #ECBA57 | Coloring OK | Coloring OK | | | | | | rgb(236,186,87) | Coloring OK | Coloring OK | | | | | | rgba(236,186,87,1) | Coloring OK | Coloring OK | | | | | | hsl(40,0.80,0.63) | Coloring OK | Coloring OK | | | | | | hsl(40,80%,63%) | Coloring OK | Coloring OK | | | | | | hsla(40,0.80,0.63,1) | Coloring OK | Coloring OK | | | | | | hsla(40,80%,63%,1) | Coloring OK | Coloring OK | | | | | | | | | | <some_tag>#ECBA57</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>rgb(236,186,87)</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>rgba(236,186,87,1)</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>hsl(40,0.80,0.63)</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>hsl(40,80%,63%)</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>hsla(40,0.80,0.63,1)</some_tag> | Coloring OK | Coloring OK | | | | | | <some_tag>hsla(40,80%,63%,1)</some_tag> | Coloring OK | Coloring OK | | | | | | | | | | "ECBA57 | Coloring ?? | Coloring ?? | | | | | | "ECBA57" | Coloring ?? | Coloring ?? | | | | | | fgColor "ECBA57 | Coloring ?? | Coloring ?? | | | | | | fgColor "ECBA57" | Coloring ?? | Coloring ?? | | | | | | fgColor "ECBA57 to get | Coloring ?? | Coloring ?? | | | | | | fgColor "ECBA57" to get | Coloring ?? | Coloring ?? | | | | | | fgColor="ECBA57 | Coloring ?? | Coloring ?? | | | | | | fgColor="ECBA57" | Coloring OK | Coloring OK | | | | | | fgColor="ECBA57 to get | Coloring ?? | Coloring ?? | | | | | | fgColor="ECBA57" to get | Coloring OK | Coloring OK | | | | | | | | | | #ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor #ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor #ECBA57 to get | Coloring OK | Coloring OK | | | | | | fgColor=#ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor=#ECBA57 to get | Coloring OK | Coloring OK | | | | | | | | | | "#ECBA57 | Coloring OK | Coloring OK | | | | | | "#ECBA57" | Coloring OK | Coloring OK | | | | | | fgColor "#ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor "#ECBA57" | Coloring OK | Coloring OK | | | | | | fgColor "#ECBA57 to get | Coloring OK | Coloring OK | | | | | | fgColor "#ECBA57" to get | Coloring OK | Coloring OK | | | | | | fgColor="#ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor="#ECBA57" | Coloring OK | Coloring OK | | | | | | fgColor="#ECBA57 to get | Coloring OK | Coloring OK | | | | | | fgColor="#ECBA57" to get | Coloring OK | Coloring OK | | | | | | | | | | (#ECBA57 | Coloring OK | Coloring OK | | | | | | (#ECBA57) | Coloring OK | Coloring OK | | | | | | fgColor (#ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor (#ECBA57) | Coloring OK | Coloring OK | | | | | | fgColor (#ECBA57 to get | Coloring OK | Coloring OK | | | | | | fgColor (#ECBA57) to get | Coloring OK | Coloring OK | | | | | | fgColor=(#ECBA57 | Coloring OK | Coloring OK | | | | | | fgColor=(#ECBA57) | Coloring OK | Coloring OK | | | | | | fgColor=(#ECBA57 to get | Coloring OK | Coloring OK | | | | | | fgColor=(#ECBA57) to get | Coloring OK | Coloring OK | | | | | | | | | | fgColor #ECBA57; | Coloring OK | Coloring OK | | | | | | fgColor=#ECBA57; | Coloring OK | Coloring OK | | | | | | | | | | fgColor #ECBA57. | Coloring OK | Coloring OK | | | | | | fgColor=#ECBA57. | Coloring OK | Coloring OK | •-------------------------------------------•---------------------------------------------•--------------------• Affect the HTML language ( Language > H > HTML ) to this text

=> You should see, at once, the coloring of the lines, in the first column

To all : an important point to note is that if you double-click on any hexadecimal numùber or within the zones rgb, rgba, hsl or hsla , it opens the Color Palette, as expected. Just test it ;-))

Howener, @michael-vincent, you can see that, for few lines, the coloring is not trigerred, although the double-click works nicely !

So, could you consider these small issues, specifically the three cases "ECBA57", fgColor "ECBA57" and fgColor "ECBA57" to get ?

As usual, @michael-vincent, there’s no obligation to do so. Just do as you please !

Best Regards,

guy038

@Hack-Lag ,

You are right, the Document List doesn’t have a way to change the order of tabs. But all you have to do is drag the tab title in the tab bar, and you can move it wherever you want… so Notepad++ can accomplish your goal, just not in your preferred interface.

That said, this feature was officially requested last year, so you could go put your comments there, in a place where the developer will see them. (As explained in our FAQ, this Community Forum is not the feature-request/bug-report tracker.)

@rdipardo Perfect, with your guide, my code works well again, thanks!

@PeterJones Thanks for the insights, Peter, but I’m not sure where this gets me.

All of these threads are about keeping the connection active. Problems are mentioned which seemingly have prevented that approach from getting and staying off the ground.

My ideas are the opposite. Kill the connection. After each upload, if that’s easiest. Triggering a file save reopens it automatically, so there is no reason to keep it alive… am I missing something?

@PeterJones said in NLog support in Notepad++?:

Analyse plugin

My first thought on reading the OP’s original post was that he is already using Analyse. Maybe not though.

if it has the ability to automatically apply styles

I don’t believe so…but it has been some time since I used it (at work) and I don’t have it at home…

Signed up to the forum specifically to say thank you for this plug in! I am back on the CNC router after a few years only to find fusion 360 have severely limited their CAM rapid paths which also slow down the feed rates on certain contours as well. this helped identify the rapids and feeds and fix them up.

Works well! thanks again!

@Coises said in ASCII compatibility questions:

I got the impression somewhere — and now I cannot remember where — that Notepad++ converts certain character sets to UTF-8 on loading (and back again on saving).

I know for certain that Geany does that. You may be thinking of N++'s option to encode “opened ANSI files” as UTF-8 under Settings > New Document > Encoding, which seems to be enabled by default. There’s a least one open issue suggesting that 8-bit ANSI is what you get when that option is turned off.

What I wondered was if, in fact, it is known that by the time Notepad++ has loaded a file into Scintilla, the first or both of the properties I mentioned will always be true of the Scintilla text.

My impression is that “Scintilla text” is always a stream of “raw” 32-bit code points; in other words, the API treats every “character” as an int, never an 8-bit char. Of course the application has to encode the stream at some point; exactly when is hard to pin down. It’s probably much earlier than anything a plugin could detect. Asking Scintilla about a document’s target encoding through any of the querying APIs returns only general information, at least in my limited experience.

@PeterJones said in Additional languages (dipping my toes into code contribution):

Accepted and merged today! 🎉🥳

I saw, downloaded and tested. Already updated my custom theme for Go. Now I just have to learn how to actually use that language :-P

Congratulations!

Cheers.