@guy038 said in Search++: A work in progress:

Thanks for including the Current Line Indicator and Caret settings within Search++. It’s worth to point out that if you modify these N++ settings during a N++ session, you’ll need to close and restart Notepad++ in order that these new parameters are taken in account by the Search++ plugin !

Another way is to change between light and dark mode; that causes Search++ to reset all the appearance information it copies from the active tab. That’s because plugins get a notification when light/dark mode changes, but I don’t think there is anything that would notify Search++ when current line or caret settings change.

A good point, though: I should either document this behavior, or reset appearance every time a Search++ window gains focus.

Now, I stumbled upon a weird bug : while within a N++ session :

If Search++ panel is already opened, click on the cross, on the far right to close the Search++ dialog

Now, re-open Search++ with the Plugins > Search++ > Search... option ( Note that I use the Docking mode )

Click on the current tab ( not within the text window ! )

Click on the Search++ windows title

Sometimes, you’ll need to repeat these last two actions twice, in order to trigger that bug

Now, try to close the Search++ panel by clicking on the cross, on the far right => Nothing happens !?

Generally, after some clicks, the dialog finally closes !

Note that I mapped the Ctrl + Shift + N shortcut to the Plugins > Search++ > Search... option. So, if I use this shortcut, I’m able to actually close the Search++ dialog in that specific case and also in all the other cases !

I would consider that it’s a minor bug and I’m not 100 % certain about the steps to reproduce it : not quite obvious !

I haven’t yet been able to get this to happen on my system. Thank you for reporting it. If I can reproduce it, I’ll attempt to figure out why it happens. What’s strange is that Notepad++ manages the close button for docking dialogs. Even if I completely remove all my close (actually hide) dialog code, clicking that X still closes the docking panel and hides the search dialog. So either you have stumbled on a Notepad++ bug, or something I am doing in Search++ is interfering with normal Notepad++ behavior.

Have you ever seen this behavior with any other docking window?

ello, @ricardo-barroso, @peterjones, @terry-r and All,

An other S/R could be :

FIND (?-i)RequiredItem.+, \K\d+

REPLACE 0

The search regex means :

First, find a string RequiredItem, with that exact case because of the leading part (?-i)

Then find any NON-zero number of chars ( .+ ) till a comma followed with a space char

Now, forget anything matched so far, due to the \K syntax

And just match a non-zero list of digits ( \d+ ), which come next

Finally, replace that number by 0

Remark : You must do a global S/R, using the Replace All button. Due to the \K syntax a step by step replacement, with the Replace button, would not work !

Best Regards,

guy038

@Olyfant22

There really are substantial differences in between the Win10 & Win11 in this area. I know about 2: SMB signing enforcement in 24H2+ and stricter token isolation (the later one should be solvable by that mentioned “EnableLinkedConnections”)

@Ronald-Besdansky Hi Terry Deleting that plugin fixed the issue. Thanks.

@arnaud-derette said in Terminal window in a N++ tab:

i think i get it : It does not handle correctly 4K screen.

That does not surprise me. Notepad++ is still not great for high-DPI environments, and it’s been taking a long time to finish some of the last-remaining high-DPI issues. And if the main app, with lots of contributors, still has issues, then it should come as no surprise that the plugins, which usually only have one developer (if they remain interested), whose skillset usually focuses on the feature that their plugin implements, rather than on the generics of all the edge cases of modern win32 coding. (At least, I know that’s true for me on my plugin(s).)

I don’t have a High-DPI environment, so I don’t know and can’t test for you, but maybe the NppExec plugin handles high-DPI better than NppConsole does (whether the original, or the intermediate fork)

@scottgshin said in autoupdater and XMLDSig:

point me in the correct direction or add the code to the N++ project

Did you check the https://github.com/donho/xmlSigner README?

And these commits:

https://github.com/notepad-plus-plus/notepad-plus-plus/commit/6f87bb7fe25350025b72fdbc711762f552f5b1ad

https://github.com/notepad-plus-plus/wingup/commit/ab8720819f9f4205ade5fe2afc56819b71a3227d

@PeterJones Thanks for the quick update to the manual! Maintaining technical documentation across versions is a major undertaking when there’s an integrated development team within major corporations; I can’t imagine how herculean that job must be when you’re not side-by-side with a lone developer, so thank you for the excellent work on it. I really do appreciate your speedy response and update.

I tried to post the second part of my list yesterday, but I was delayed by the “time between posts” counter, and unfortunately had to leave before it reset.

However, you might want to double check your list against the FAQ, to let us know if the FAQ is missing any.

I’ll go ahead and do that. Thanks again!

@PeterJones

That “Stopped working” is a common overall expression there for the app crashes, hungs etc.
So @mapsonx should open that “details” you mentioned or simply launch the Windows EventViewer, i.e.:

press WinKey+R to invoke the Windows Run-dialog copy & paste there: eventvwr.msc /c:"Application" and click OK wait for the Event Viewer launching and attaching to OS logs search/filter there for “Error” Level records (or simply follow the ReliabilityMonitor published date/time of the N++ problem), with “notepad++.exe” within app crashes usually have as log Source “Application Error”, frozen apps “Application Hang”

Then publish here what the content of such a record tell us, e.g.:

Faulting application name: notepad++.exe, version: 8.9.3.0, time stamp: 0x69bc8a94 Faulting module name: USER32.dll, version: 10.0.19041.6926, time stamp: 0xcd1afcbd Exception code: 0xc0000005 Fault offset: 0x00000000000467cd Faulting process id: 0x296c Faulting application start time: 0x01dcce3ba0a16cb7 Faulting application path: ...\npp.8.9.3.portable.x64\notepad++.exe Faulting module path: C:\Windows\System32\USER32.dll

@Lars-Hesselberg said:

the Find dialog seems to pop up where it left at last Find.

This seems very reasonable to me.

…sometimes a “Seek & find”!

Shouldn’t be…it’s where you “left (it) at last Find”.

Summary: Put it where you want it to appear always, and it will always appear in that same spot.

@Hiroki-H1974 said in The Column count of Zenkaku chr. is 1?:

So, the position is not the same even if Col: count is same because the line contains some Zenkaku chrs.

I don’t know Japanese; please forgive me if I’ve missed the point in some way.

The column (“col:”) in the status bar is just a count of characters from the beginning of the line, starting at one. (That’s not even always what you might expect; combining characters that form a single visible character are still counted separately.)

Aside from a few things like cursor positioning, line wrapping and selection with the mouse, Notepad++ (like the Scintilla control it uses for editing) doesn’t concern itself with the physical space occupied by characters. In English, we can use a proportional font, and a line of twelve characters will show the next “column” as 13, whether they are IIIIIIIIIIII or WWWWWWWWWWWW.

So (though I haven’t attempted to test it), regardless of font, I would expect that there would be no recognition of the difference between half-width and full-width characters.

@William-Fields said in Curse of the Curly Quotes:

When pasting code into NP++ from another source, no matter what I do, if the source has curly quotes, the pasted content has curly quotes.

Right. That’s because the curly quote characters have different codepoints from ASCII quotemarks.

It’s doing the right thing.

If you want to convert, then use a regular expression:
FIND = [“”]
REPLACE = "
SEARCH MODE = Regular Expression
REPLACE ALL

change all curly quotes to straight quotes when opening documents or pasting content

There’s no such command or option in Notepad++, because that would be Notepad++ changing characters from one codepoint to another without user interaction, which is the antithesis of text editing

https://community.notepad-plus-plus.org/post/102348

The Direct Write ligature-effects from the post you showed is just the fonts changing the appearance of characters based on font ligature rules, but the underlying characters that Notepad++ is presenting are the exact same characters as found on disk. On the other hand, the curly quotes that you are copying and pasting are different characters from the ASCII quote.

@martin-honnen ,

Please be careful when forking and keeping the original name for an apparently-abandoned plugin. Sometimes, it turns out it wasn’t as abandoned as thought – something like that happened with NppConsole plugin (as obliquely mentioned in a recent Topic here): a few years ago, it appeared abandoned, so a regular here took the source code, and made their own fork, but kept the original name (thinking it would be safe, because it appeared to be no longer supported in the original channel); but then, fast forward a few more years, and the original author did provide their own upgrades to the original plugin – so now there are two competing development paths, each having version numbers not present in the chain for the other, which will make any future questions in the forum confusing, as to which NppConsole plugin is actually being talked about.

Similarly, if morbac ever decides to come back to the plugin, then your fork and the original could have conflicting and/or confusing version numbers and naming.

I would highly recommend coming up with your own name for your product, if you are planning to continue development and support on your version of the plugin. If it’s really just a one-off thing, and you aren’t planning on future bugfixes/improvements/support, then it’s up to you whether it’s worth the rename; but if you want to continue to work on the plugin, then I’d suggest the rename.

OTOH: if you can get permission from @morbac to take over completely, then it’s safe to keep the original name, because you’ve got the permission. (It’s most clear, in cases like that, if you can get write permission to the original repo – @chcg was able to do with @bruderstein’s PythonScript, and that sense of continuity makes it more obvious that his is still the “official” PythonScript.)

@PeterJones Ah yah, I understand now. I suppose this is a fine solution, so thank you for that. This still requires some finesse to get in front of the 1st column versus just click+dragging inside the margin, but definitely better than before. 😎

@tauniaxd ,

I have added the ability to do rgba(0,127,127,0.05)-type colors to the on-demand script at
https://github.com/pryrt/nppStuff/blob/main/pythonScripts/nppCommunity/21xxx/21044-ColorizeHtmlCssColors.py

1e6ece19-b4de-4475-b379-0649d96b2d4f-image.png

If you prefer full underline, then change lines 24 and 26 of the script to use INDICATORSTYLE.PLAIN instead of INDICATORSTYLE.DASH

aa370073-5db8-4431-b80e-7ffc21b3c61c-image.png

@Lycan-Thrope
美国干涉台湾，又怎么说？
台湾的绿圾执政党，自甘堕落化为纳粹，由不得别人不干涉！