Hi, I would like to test your plugin but, unfortunately, I run windows arm-64 and this plugin only runs on x86. Do you think it’s possible to release an ARM version ? Thank you.

@Javier-Utrilla said in show the current zoom: something like U | Zoom +10 It’s fine…but why not make the abbreviated encoding MORE descriptive, and the zoom info LESS descriptive. E.g. (just my thinking): U8B |Z+10

@Ivo-Krab said in Support for Plugins Admin & NppPluginList: but modifying the C:\Program Files\Notepad++\plugins is understandably blocked without admin access. Would it not be possible to allow (as a config choice) to install them in %APPDATA%\Notepad++ instead The problem is that plugins in Notepad++ can do anything Notepad++ itself could do. They are C++ programs operating in the same security context as Notepad++ itself. From a security standpoint, allowing plugins in a directory that can be modified without admin access would be equivalent to allowing access to Program Files without admin access. As I recall, that was allowed at one time, and this is why it was removed. Security-sensitive organizations determined that they could not install Notepad++ at all unless they could stop users from installing their own plugins. The developer decided it was better to remove the capacity entirely than to try to implement a switch of some kind. The work-around, if you can run programs that are not installed in Program Files, is to use a portable copy of Notepad++. If you are not allowed to do that, then logically you would be forbidden to run Notepad++ plugins in a directory you control, since it would grant you exactly the same access.

@xMRi As far as I know, no. Npp explicitly checks this and throws an exception if no function is defined. So I would say, use an “About” menu item.

@donho said in v8.8.9 and ConfigUpdater plugin: @PeterJones It’s already fixed in the GitHub, but I didn’t make the plugin list cutoff deadline. Are you talking about it? https://github.com/notepad-plus-plus/nppPluginList/pull/999 It’s in the current PluginList in RC normally. I ran: Plugins > ConfigUpdater > Reset Validators Plugins > ConfigUpdater > Update Config Files The open tab with ConfigUpdater.log no longer shows any errors

@h-jangra It could be, yes, because I downloaded it and ran setup_arm64.bat in a normal cmd shell, and it worked. But it could also be due to how you originally set up Rust. I also played around with this a bit, but couldn’t reproduce your problem. I had MSVC installed via the Visual Studio installer, and then I installed the Rust toolchain. Some weeks later I add the arm extensions for VS and added the target to Rust, and it works for me.

@Ekopalypse I tried simple plugin now using go. It did worked, let see if I can improve. If its good then I should make template for it.

@h-jangra I doubt that you can implement this in Scintilla in a reasonable way, but the other idea of having a preview is there, and there are at least two plugins, here and here that can give you some ideas.

after a look at jn-npp-plugin on github it seems Win32 API is not available in win x64 and i didn’t find other way to use openfiledialog… i am looking at python plugin now . thanks for your help

In case anyone is interested, I’ve created a version of this that runs as a Windows application rather than as a Notepad++ plugin, so it works in all applications: Compose for Windows This should be considered experimental. Since it works everywhere, not just in Notepad++, it has more potential to mess things up if I’ve missed something. Since it has no connection to Notepad++ (other than being a spin-off of the plugin described in the original topic message): The convenience features for editing a user definitions file which I added in response to @PeterJones’ notes aren’t included. Further discussion will be off-topic here. Please raise questions and concerns in the Issues for the project. The actions to create GitHub pages are, for some reason and at least temporarily, not working on this repository, which affects the normal presentation of the help file. However, you can still read the help file here (though some links appear to be garbled).

@notdodgeball said, If you are talking the MarkdownViewerPlusPlus plugin by nea, its indeed been dormant for many years, although I suspect it still works and you may have a problem on your end. I can confirm MarkdownViewer++ still works… in that I still semi-actively use it in Notepad++ v8.8.7-64bit (it’d been a few weeks since the last time, so in case I had misremembered and it was on v8.8.5 that I’d last used it, I double-checked today, and it can still display my Markdown) @Dragon-Red said, Do you plan to upgrade the DLL so that this plugin is usable again? In case you were curious, this Community Forum is the Community of Notepad++ users. Further, plugins are maintained by their respective authors or maintainers, not by the Notepad++ Developer, so even if you incorrectly thought this Community was the way to get in contact with the Notepad++ Developer, he’s not the right one to contact when you want an fix for a plugin. (And, as @notdodgeball told you, MarkdownViewer++ is effectively unmaintained at this point, unfortunately.)

@Wes-Owens Here is the procedure, which is 100% reliable for me: Ctrl+F, enter search terms, FIND ALL IN CURRENT DOCUMENT Find Dialog closes. Search Results dialog is shown Hitting F7 will toggle between the Search Results and Editor having focus If Search Results has focus, it will have blue title bar If editor has focus, you will be able to type in editor If Search Results has focus, hitting ESC will close it See this animated screen grab: [image: 1762206430355-3ca2bc47-53e2-4871-b24b-80793ab27d1a-searchresultsf7-esc.gif] edit: even if I have the setting that @Terry-R mentioned checkmarked: I see the Search Dialog after hitting the FIND ALL IN CURRENT DOCUMENT button, I still see that the Search Results window is given focus when I do (see the blue title bar for that panel): [image: 1762206605143-f034944b-732d-455c-a662-8c445c4d0573-image.png] And when the Search Results have focus, the SINGLE KEY ESC is sufficient to close the panel.

XBrackets Lite v2.0.3 Glory to Ukraine! Glory to the heroes! fixed: CXBracketsLogic::OnCharPress was truncating a multi-byte character to a single-byte one, thus incorrectly treating e.g. 0x1D5B as 0x5B which is ‘[’. https://github.com/d0vgan/npp-XBracketsLite/releases/tag/XBrackets_v203

@Laurie-Stearn said in Columns++ display anomaly: Out of interest, getting similar behaviour in a UDL when selecting Arial as font as opposed to Consolas: <WordsStyle name="COMMENTS" fgColor="008000" bgColor="000000" colorStyle="1" fontName="Arial" fontStyle="2" nesting="0" /> As before type a long line of text which overflows the wrap limit thus texttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttexttext Then insert before it the opening comment tag: /* Solid pink line appears below the long line which prevents any cursor movement below with down-arrow. Replacing Arial with Consolas for example doesn’t repro. Some rare irreproducible glitchiness with pink lines may occur in other situations by just typing the slash instead of the asterisk. Edit: Just realised this is for a plugin not installed - the issue seems to be with N++ itself. Sorry. When it happened with my plugin (Columns++) the cause turned out to be a wrapped line getting shorter (due to tab layout changing), so that it needed one less wraps. The solution involved temporarily disabling Scintilla’s line cache: something that can cause slow processing in large files with word wrap on. The problem doesn’t happen when editing itself makes the line shorter; it happens when something done after the editing is complete (like recalculating tab widths, or changing styles) causes the line to get shorter. My guess is that in this case, the text wraps to n lines after editing, before the new styling is applied; then, when styling is applied, the text only requires n-1 lines for wrapping, and the leftover line is magenta-marked. That marking is a Scintilla “feature” to show that something went wrong. (Why it doesn’t just correct the wrapping instead, I don’t know. Scintilla is open source, but it’s still pretty much a black box to me.) The practical fix is probably to avoid specifying different fonts (or font variations with differing widths) for different styles if you expect to use them with word wrap. For performance reasons, turning off the Scintilla line-wrapping cache would not be something Notepad++ would do.