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

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

@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);