It does not work for me. It seems never to receive keyboard focus although I can click my mouse and copy text from the results window, nor is there a delete entry in the context (right-click) menu. All keyboard events go to the active tab window

@Vitaly-Gelman ,

I wonder if there is a way to set a background to grey for a disabled block of C code

Use editor.styleSetBack(...) instead of editor.styleSetFore(...)

Also, where can I find a description of editor.styleSetFore() function

If you click on editor.styleSetFore() in your script inside Notepad++, and use Plugins > PythonScript > Context-Help, it will take you to the PythonScript documentation for styleSetFore, which tells you that the second argument is the color

namely the second argument (clr). What are the three integers there?

The “color” to use. Specifically, the three integers in the tuple are the red, green, and blue values. In my calculation, I had it set the “disabled/hidden preprocessor section” (aka “SCE_C_PREPROC_HIDDEN”) to the foreground color that’s halfway between the foreground and background of a normal preprocessor (which is a reasonable hidden value, whether in Light Mode or Dark Mode).

So if you want to set the background, you would have to pick red/green/blue values that make sense given your theme, and use editor.styleSetBack(self.SCE_C_PREPROC_HIDDEN, ...) where ... is either a tuple variable (like clr) or a literal tuple (like (63,63,63)).

(Please note that Scintilla, and thus Notepad++, treat the #if 0 exactly the same as the #ifdef NOTDEFINED, so there is no way to distinguish between a hardcoded #if 0 and the define-based #ifdef NOTDEFINED – so I hope you weren’t asking to be able to distinguish between the two, as you would be disappointed if you were.)

—

PS: the styleSetFore() didn’t specifically describe that a “color” was in a tuple, because near the top of the Editor Object page, there is a paragraph which says,

Colours are a tuple of (red, green, blue) where each of red, green, and blue is between 0 and 255.

… and that paragraph applies to all “color/colour” arguments throughout the documentation.

So glad this is in the latest build!

Small Demo here:
https://www.reddit.com/r/notepadplusplus/comments/1e6eceq/blitz_search_in

@Raff-Zahn said in Npp and plugins, font size of the representations:

In Windows 11 I set the display to 125%. Npp does not handle the adjustment.

That’s strange. On Windows 10, I have two monitors; one is scaled at 100% and one is scaled at 125%. The size of menu text, icons and editable text changes when I move the Notepad++ window from one monitor to the other (unmistakably visible as I drag it across, because when the window changes from being mostly on one monitor to mostly on the other, the size changes on both monitors). If the display scaling is really not affecting Notepad++ in your installation, there must be some reason; normally, it does.

Is there a way to adjust and zoom the representations in plugins?

Plugins in Notepad++ create their own user interface, aside from docking dialogs when docked (and even then, it’s only partially under the control of Notepad++). You would have to make your request to the author of the plugin in question; usually there is a GitHub issues forum.

Hi,
did you install the C++ development tools when installing Visual Studio. This is mandatory for developping the Npp Plugin.
Regards
Guido

My ancient Oxford English is very bad? I actually have a poor understanding of US English here in the forum. So I have to use a translator. Thanks for the tip.

Actually, it’s not QuickText but the Snippets plugin that’s right for me. It’s much more elegant than Panel in the old Weaverslave.
As a docking popup it’s OK. I expand the left editor margin to the maximum, make the snippets quite narrow, use very short tag names, put the line numbers and the margin in the snippets. So it’s almost perfect.

Thank you for help. I’m already happy with the npp. Must see, Donate is mandatory.

Russian is the first language translation completed. Thanks to AlexERistGIT.

There are still a few more languages left to go ;-)

If you are a native speaker of a language other than German or English, feel free to join and help with further translations.

@PeterJones said in Support for Plugins Admin & NppPluginList:

Let me know if that procedure […] is able to work for debugging.

Yes, it works. Thank you.

I didn’t bother to examine the code to find out how it works, but apparently using a debug version of Notepad++ automatically uses the .json plugin list instead of the .dll, so the test proceeds just fine. Just to be sure, I tried changing my plugin’s hash value in the list and it flagged the mismatch, so it is validating the hash.

I don’t think that’s an unreasonably difficult procedure for plugin authors to follow (relative to the work to actually write and debug a plugin!). It’s not a big deal if updating those fixed-URL debug builds is inconvenient. It would just be good to have the procedure documented, either in the manual or in the plugin list readme (to which the manual could refer — personally, I think it makes more sense in the plug list readme).

@PeterJones said in I was ambushed by the 63-character limit for plugin menu item names:

Given that the menuItemSize doesn’t affect anything except the size of the Plugins’ menu entries in TCHAR _itemName[menuItemSize], and the equivalent for built-in context menus is generic_string _itemName , which doesn’t have length restrictions, I think it’s worth trying to ask Don to allow for an increase (“Notepad++ menu entries don’t have a length restriction, but Plugin menu entries do” seems a solid argument, to me).

Changing that would break existing plugins. It’s hard-coded into the C interface.

@Mark-Olson
I’m coming a bit off the top of my head here, but I see no way Notepad++ could offer a message, since the length limit is hard-coded into the interface structure. If you’re supplying more than 63 characters, you have, by definition, broken the interface.

If you hard-coded a character string of more than 63 characters into a C/C++ program using that structure (as I use it here), you’d get a compile time error.

As I understand it, plugins that choose to be translatable must supply their own translation mechanism; Notepad++ doesn’t do anything about that. I believe it must be the translation process in your plugin that is copying a string without checking the acceptable target length first.

@0BZEN said in Little script is very slow (depends on file size):

Not necessarily, no, it’s just very convenient, especially with shortcuts.

I’m just saying, select, Ctrl+M, visually confirm checkboxes, and click Mark All isn’t that onerous… and if your script is “very slow”, it’s sure to be faster than >15sec for the script version.

Possibly, although that will get invalidated when the file content changes

Mine doesn’t cache that information from run-to-run. It just precomputes the mapping of the positions-from-lines in a way that only requires going through the whole document once (as far as I can tell), rather than counting from the beginning every time.

Yeah, the search results don’t contain meta-data, like line numbers. It might be possible to count the number of ‘/R’ characters from the last hit, the first search result using the slow function (or count the ‘/R’ from beginning of file).

I’m pretty sure that the extra effort of counting between matches (which isn’t implemented already, so it’d have to be manually done) would be more time-consuming than the current.

@Jens-Lindhardt ,

There is a User Defined Language Collection at
https://github.com/notepad-plus-plus/userDefinedLanguages , where users can share their UDL definitions (along with AutoCompletion and now FunctionList definitions that go with that UDL)

@Dave-Mear ,

Specifically for that? Not that I’m aware of. But…

The NppExec plugin has Console Output Filters, which will color error messages (and similar) for things that are printed into the NppExec Console – and double-clicking on those lines in the NppExec Console will take you to the right file and line number (and even character position in the line, if your error log is that specific). So if you set up an NppExec script that ran cmd /c type "$(FULL_CURRENT_PATH)" , it would take the contents of the current file and print them in the NppExec console.

So if you use Plugins > NppExec > Console Output Filters to define a pattern that matches the errors in your specific format. The NppExec_Guide.txt help-file that comes with the plugin shows examples for gcc warnings and errors:

Example 1: %ABSFILE%:%LINE%: warning:* => detects the warning lines from gcc
Example 2: %ABSFILE%:%LINE%: error:* => detects the error lines from gcc

(The %CHAR% sequence will match the character-position number)

Further, you can use NppExec to actually run your compiler or build process, so if you wanted to skip the temporary error-output file, you could run the build inside NppExec (from a script or manually typed in the Console) and just allow the build to output to STDERR as per normal inside the Console, and NppExec would still be able to see the errors.

@conky77 I deal with it by searching the manual and have a shortcut for https://www.google.com/search?q=site%3Anpp-user-manual.org

For settings/preferences I sometimes look at the config.xml file and have another shortcut that opens that file using a portable copy of Notepad++… It’s often faster for me to search and edit the config.xml file than to try to remember where in the sub-menus of the preferences a setting is found.

I agree though that modern software seems hard to navigate. You are in a maze of twisty little passages, all alike. :-)

@PeterJones said in show the current zoom:

try to start a language-war with the proponents of Python

No saber-rattling detected…or intended with the following:

My history is Perl first, then Python – standalone, not PythonScript.
And both were for text processing type things; for other things I’ve always been a C/C++ person (mainly C).
The old command-line guy in me really liked Perl’s quirkiness, perhaps readers know what I mean … command.com’s interpreter really had/has a bunch of quirks.

However, as much as I liked Perl at the time, I found that if I “put it down” for a while, it was really hard to come back to it (due to ever-advancing age perhaps). With Python, I found it just sort of flows from the fingertips, so to say, and was easy to come back to after some time off. Aside from maintenance of some large scripts I wrote and still use, I haven’t done any new Perl in many years (perhaps a decade?).

I was rather pleased when I discovered Notepad++ and saw that its most popular scripting plugin was Python-based. (This might be the only sentence in the post that is on-topic).

But overall, I see no need for “language wars”.
I’m reminded of the quote from the Lord of the Rings (movies): “Go off and die in whatever manner most suits you” (or something like that).
In this case, “Go off and use whatever language most suits you, as long as it gets your job done”.

@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.