Hello, @coises and All,

I’ve just tried your last ColumnsPlusPlus v1.3 release and indeed, the search is now considered as a true Unicode search, whatever the individual encoding of each file !

Let’s consider this simple UTF-8 text :

This ‟ is a † very • small ‰ text ‱ for › test 201F 2020 2022 2030 2031 203A in Unicode UTF-8 enoding

And this ANSI text :

This ? is a † very • small ‰ text ? for › test ? 0086 0095 0089 ? 009B in Windows-1252 encoding

IMPORTANT Don’t forget, when this second text is opened in N++, to run the Encoding > Convert to ANSI option, first !

Now, we can create the following table, which recapitulates the Non-ASCII characters used in my examples :

•--------•-----------------•-----------------• | | Windows-1252 | Unicode | | •--------•--------•--------•--------• | Char | Dec | Hex | Dec | Hex | •--------•--------•--------•--------•--------• | ‟ | ? | ? | 8223 | 201F | | | | | | | | † | 0134 | 0086 | 8224 | 2020 | | | | | | | | • | 0149 | 0095 | 8226 | 2022 | | | | | | | | ‰ | 0137 | 0089 | 8240 | 2030 | | | | | | | | ‱ | ? | ? | 8241 | 2031 | | | | | | | | › | 0155 | 009B | 8250 | 203A | •--------•--------•--------•--------•--------•

In Notepad++ :

Within an ANSI file, the regexes [†-‰] or [\x86-\x89] would only find the characters † and ‰ but not the • whose Win-1252 code ( \x95 ) is after \x89

Within an UTF8 file, the regexes [†-‰] or [\x{2020}-\x{2030}] would find the characters † and ‰ and also the • whose Unicode code-point is between 2020 and 2030

In Columns++ :

Within an ANSI file, the regexes [†-‰] or [\x{2020}-\x{2030}] would find the characters † and ‰ and also the • whose Unicode code-point is between 2020 and 2030

Within an UTF8 file, the regexes [†-‰] or [\x{2020}-\x{2030}] would find the characters † and ‰ and also the • whose Unicode code-point is between 2020 and 2030

Note that using the range [†-›] within an ANSI file, a N++ search of the • char would have been successful as its code-point ( 2022 ) lies within the 2020 and 203A range !

Now, @coises, I cannot test easily the CJK behaviour of your new search engine as it’s obvious that I do not a default CJK code-page, needed for such a study ! However, I do not see why your new search behavior couln’t be applied to any kind of Unicode chars ;-)

Best Regards,

guy038

There is one more thing that requires an explicit mentioning in the documentation:

When exactly NPPN_CMDLINEPLUGINMSG is sent to plugins? In particular, is it sent before or after NPPN_READY? (Currently it is sent before NPPN_READY. But will it be so in the future?)

I wrote in SCI_GETCODEPAGE is NOT always either 0 or 65001:

When I did a test by changing my system default character set to Japanese, I started a new file, set it to ANSI, and pasted in some Japanese text. SCI_GETCODEPAGE was 932. I saved it that way. When I opened it again, the encoding was set to Shift-JIS — not ANSI — and SCI_GETCODEPAGE was 65001.

For future reference:

This only happens if Settings | Preferences | MISC | Autodetect character encoding is checked. When it is not checked, the file opens, as expected, as ANSI (SCI_GETCODEPAGE returns 932).

@PeterJones said in Handling Ctrl+C in a c++ plugin dialog:

I interpreted as wanting to have a keyboard shortcut specific to an action inside the dialog.
[…]
It would very much surprise me if it weren’t possible for a plugin to do that (though I cannot think of any off the top of my head that do so). But whether “subclassing” or some other strategy is the right way to implement the shortcut capture is beyond me.

(Following based on theory/understanding. I have not actually tried to do this.)

Subclassing the NPP window would be horrific way to go about this (if it would even work at all). Making shortcuts work specifically in a plugin window is a bit of an awkward problem, because (as far as I can tell) there is only one accelerator table for an entire running program — and Notepad++ already “owns” that table.

In a modal dialog or a non-modal window that was registered with NPPM_MODELESSDIALOG it wouldn’t work at all, because messages for those don’t go through TranslateAccelerator. The message would get sent to the window/dialog. This is actually the right way to go, but subclassing the main NPP window would be irrelevant, because the message would never get to that window; it would be dispatched to the plugin window or one of its controls.

For a non-modal window without NPPM_MODELESSDIALOG, the shortcut key would still send whatever menu command was assigned to it. In that case, a subclass procedure could check whether the keyboard focus is in a window belonging to the plugin. If it is, process it; if it isn’t, pass it through normally. But note that you’d be catching the command, not the shortcut. Your command would always take over from the NPP command, regardless of whether it was by menu, by tool button, or by whatever shortcut key the user assigned to the NPP function.

For modeless dialogs that don’t register, NPP now works around this for cut, copy and paste by sending WM_CUT, WM_COPY and WM_PASTE to the window/control with keyboard focus when one of those commands is invoked and focus is not in an NPP-managed window or control. Note that if you change the shortcut for one of those commands, the dialog will respond to the new shortcut. (It will respond to the “normal” shortcut as well if and only if that shortcut isn’t assigned to a Notepad++ command. Scintilla assignments don’t count; that’s why the problem didn’t show up until the shortcuts were moved from Scintilla to Notepad++.)

So to get it right, you have to register the window if it is modeless, and you have to pick up the key combination in your plugin code. How to pick it up is a bit of a pain in the butt, because usually the main window (typically a dialog box) won’t have focus, so the keystrokes will go to whatever control does have focus — unless the dialog manager captures it and applies its own logic (such as it does for the tab key and for Alt+ accelerators).

I still haven’t found a clear and complete description of what the dialog manager does when the message loop calls IsDialogMessage. Part of it is bound up with WM_GETDLGCODE, which is sent to controls — not the dialog procedure — which further complicates things. Subclassing every control which could have focus when you want your key combination to work would probably be necessary. I suspect some key combinations cannot be captured, but I don’t know that for a fact.

It’s messy. Finding another way — like adding a button for your action and then underlining a letter so that Alt+letter will activate it — is likely to be a lot easier and less fragile. (If the action is control-based, rather than independent of which control in your plugin has focus, then of course the way you did it is correct.)

@PeterJones ,
Good point. Luckily, it’s still one of a handful of functionList files…at least until you figure out how to mass produce those. :-)

A new version of MultiReplace (v4.5.0.30) is ready and will be available with the next Notepad++ release. It can be dowloaded here.

The focus of this release is on expanding the search functionality and giving you more flexibility.

Implemented updates:

Find All: This is a new feature that lets you find all matches and see them in the search results window. It’s not limited to the current file – you can also search across all open documents or in entire folders.

GroupResults: To go with “Find All,” this new INI option lets you choose how your results are displayed. You can see them all mixed together in document order (the default), or neatly grouped by each list entry, which is great for getting a clear overview of complex searches.

lcmd: A new command for the “Use Variables” feature. It allows you to load your own custom helper functions from external files, which opens up a lot of possibilities for complex and reusable logic.

AllFromCursor: Another new INI setting that gives you more control. You can now choose to start “Find All”, “Replace All” and “Mark” operations from your current cursor position instead of from the top of the file.

Here is a visual take on the changes:
MultiReplace45.png

New try: Now it works, like you described it. Seems I set it up wrong!

@General-Coder
I had the same issue when I installed a new Visual Studio 2022 and forgot to install the packages for C++ development.
Regards
Guido

@PeterJones said in How dynamic-ID menu commands are executed and relation to macros:

There is no “universally constant value” necessary for Notepad++ to store for it to be working the way it is.

And creating a new identifier rather than using menuCmdID is not likely to happen (nor should it, IMO)

That scheme (even if hypothetical) seems to work very well as long as it’s not a problem that the IDs change when you remove menu entries.
But we do know that it is in fact a problem for recording macros.
Here are 2 approaches I can think of (besides the “shut up and hack the XML files” one :) ) :

A. Constant IDs version

Still have a linked list to represent the structure of the (dynamic) menus, but whose contents are just the IDs of those commands. Can still be in same range as current IDs, if needed.
Add a dictionary (hashmap) to map from those IDs to the respective actual commands, or in case of macros - list of actions , as you describe in your post above.
Npp getting command 20001 for ex, involves looking up in the dictionary - most often a constant time operation.

Deleting an menu entry involves deleting the respective entry in the linked list and also the ID-value pair in the dictionary.

In addition to that, to ensure that generated IDs stay within a given range: Several schemes are possible, one of the simplest can be just generate a key in range and test that it is not present in the dictionary.

B. Dynamic IDs, but synchronized in every saved macro

Basically, keep the scheme as it is at present, but add a way to update, for each macro, every stored referenced menu command ID in an Action record:
at every removal of a menu entry, compute how the rest of entries’ IDs would change (if located After those removed, the ID would decrease by one) and traverse the linked list of all macros and update that ID in every action that refers to a menu-command in the range of the dynamic-IDs types (Run, Plugin and Macro commands).
Thus on Npp closing, the macros written in XML will also contain updated IDs.

But don’t pretend the niche [for a more powerful macro system ] doesn’t already have a plethora of entries.

I think there is plenty of room for a macro system to grow in power and STILL be much easier to do a lot of common tasks, than the same tasks in any scripting language.
Because with macros you don’t have to learn and remember syntax.

@erik-neyman
Hi,

first of all, please hide/change your secret_key setting (or remove the image), as this is a public forum and others may misuse it. :(

Unfortunately, there may be bugs in the latest NppOpenAI v0.5 update (updates/fixes can be found on the NppOpenAI development project page), so I suggest that instead of setting a route_chat_completions, you should specify the URL “all at once”, e.g.

api_url=https://api.openai.com/v1/chat/completions

Edit: You can leave the route_chat_completions setting unchanged.

I apologise for the error!

@Ekopalypse
Wow, thank you!

Has anyone here found how to open those relative path links from within the Notepad++ file, in their default app ?

That would make the solutions listed here even more useful IMO; one could have for instance have the documentation of a project in simple text files.

Opening the links at either double-click (better, & underlined) or some other action.
I’ve requested the feature on github https://github.com/notepad-plus-plus/notepad-plus-plus/issues/16942

Updated linter++ to v1.0.1

Most obvious changes:

Works properly in 32 bit mode Ability to switch linting off and on - mainly for people with slow PCs Double clicking on an error in the ‘system’ tab will open a new notepad++ buffer and provide more detail on the error Ability to define your own variables to be used in commands.

This is available at the same page as above.

@Mit-Jean ,

Notepad++ has a plethora of ways to decide which file(s) should undergo search/replace. I am not convinced it needs another.

One document: Search > Replace > Replace All = does replacement whether there’s a saved file or not All open documents: Search > Replace > Replace All in All Opened Documents = does replacement whether there’s a saved file or not Across multiple files: Search > Find in Files > Replace in Files = does replacements only in files saved to the filesystem Across a specific set of files in a “Project”: View > Project Panels > Project Panel N, then in the Project Panel, Right Click on the workspace > Find in Projects (or Search > Replace, pick the Find in Projects tab) and then run Replace in Projects

My original thought was that, instead of somehow “marking” a file for “MOD scope”, you would just add your file to the project, and use Find in Projects. But since you want to include documents that haven’t been saved to a file yet, that won’t work (because Projects require that there’s an underlying file for everything added to the Project). However, I might give the advice that it would improve your workflow (and reduce the chances of losing data) if you were able to update your workflow to always save a file to the filesystem before doing any search/replace in it (especially as a multi-file S/R, as that’s a situation where you might not notice right away that your S/R didn’t work quite as expected, and you might move beyond the undo-history before you discover your mistake). (My personal opinion is that anyone who tries to do any more editing than Create File then Save, or maybe Create File then paste boilerplate then save, is just begging their computer to lose data for them: computers crash, and applications cannot perfectly/flawlessly prevent loss of data when they do; having unsaved data is foolish, IMO. For the ephemeral stuff, I have a “scratchpad” document always open, and I make liberal use of the AutoSave plugin, as described in this FAQ. My only exception to this rule is that I often create an empty unsaved tab to paste in data from a post in this Community, verify my suggestion works, and then delete it, all with it never being saved to disk; but that’s because I know that there is a 0% chance that I would care that the data were lost if my computer crashed while I was in the middle of it, because it’s data copy/pasted from the forum.) But enough of my preaching.

If you were to make an official feature request – like @Alan-Kilborn hinted with his link – then I would say don’t word it as you currently do: Notepad++ already has a way to apply a specific color to a document’s tab (right click on the tab, Apply Color to Tab > Apply Color N), so instead of creating yet another way of marking the file for your “MOD scope”, what I would suggest is asking for “Replace in All Tabs of Color N” where “N” is 1…5 for the five possible colors; this would make the interface very similar to the Find in Projects dialog, where you can select one of the three project panels. That way, instead of having some new concept of “MOD scope”, it would be making use of a way that Notepad++ already provides to indicate similar tabs – it would actually give you five independent “MOD scopes” simultaneously, without introducting another new concept to the N++ interface.

Hello, @peterjones,

My bad ! Thanks to the @dinkumoil’s post, I realized that you already fully documented the npp-compatible-versions and old-versions-compatibility attributes in the official N++ documentation ! So, most of the initial posts about this topic seem useless :-((

Anyway, this was the occasion to revisit these important notions. As an example, if we consider the true maximum syntax, each made of 3 elements, which is :

- "version": "a.b.c", - "npp-compatible-versions": [d.e.f,g.h.i], - "old-versions-compatibility": [j.k.l,m.n.o][p.q.r,s.t.u],

My understanding supposes that this means :

Latest plugin version a.b.c of the plugin works with all releases of Notepad++ between d.e.f and g.h.i, included.

Older plugin versions between j.k.l and m.n.o, included, should work with all N++ versions between p.q.r and s.t.u , included.

The plugin version a.b.c is more recent than, both, the versions j.k.l and m.n.o of that plugin.

This example likely represents the case of a plugin no longer maintained after the N++ release g.h.i.

As always, RTFM ;-))

Best Regards,

guy038

@rdipardo

But what if the given document is not UTF8, but ANSI or UTF-16?

I’ve finally gotten around to implementing a fix for this issue in JsonTools. I did this first in JsonTools because it has a lot of features that read the text of the file. It appears to work fine for ANSI files (you can test it on this example file I added).

As I noted in the commit message, there are some features that are broken because my JSON parser’s code for determining node position assumes that the document is UTF8-encoded.

…or UTF-16?

JsonTools has always worked correctly on files with any encoding except ANSI, so at least on my machine, I have just confirmed that Notepad++ internally represents documents as UTF-8 if the file itself is in UTF-16 or some exotic encoding like OEM 865.

@User-Name said in JsonTools v5.5. is live!:

And then if I open any file, it opens formatted.

Glad to hear it!

But the first opened file is not formatted :)

That’s probably just a limitation of how PythonScript is implemented, and I don’t think there’s anything I can do about that.

@Vitalii-Dovgan said in XBrackets Lite v1.4.0 has been released!:

The uniqueness of XBrackets is in its external simplicity and internal complexity.

Thank you. I get 3) from the SurroundSelection plugin. Notepad++ has “Go To Matching Brace” in Search menu, but I think it only includes { [ ( ) ] }, not quotes.

Cheers.

@Alan-Kilborn said:

I think it should be an absolute requirement that the title bar always starts with Notepad++ -

Hmm, this is what I get for posting when I don’t have Notepad++ right in front of me (i.e., I get it wrong). :-(

Now that I have it in front of me, the Notepad++ title bar shows pathname - Notepad++ or filename - Notepad++.

My point was mainly about Notepad++ remaining somewhere in the titlebar, because this bit of consistency aids in other programs in locating the N++ main window, via the FindWindow Win32 API call. I do this a fair amount, and thus I’m projecting that I’m not alone and that others do this as well.

Here’s a bad example; some PythonScript code:

notepad.hwnd = user32.FindWindowW(u'Notepad++', None)

(It’s “bad” because it isn’t necessary any longer, because newer versions of PythonScript have the notepad.hwnd variable predetermined for you – but for a long time this was not the case)

But, if Notepad++ weren’t in the title bar text, it would not be as “easy” to locate the window, for those that need to.

Note that the OP made no suggestion to drop Notepad++ from the title bar text; I was just thinking if the original idea was extended (as tends to happen), I’m sure someone would come up with that idea. And @Coises did call the text redundant, so that could be construed as a first step at “removal” – in quotes because of course all of these suggestions would be for optional things.