@peter-wall said: It works if that setting is off. It works, full stop. You just need to understand the documentation. As ScintillaDoc says for SCI_SETFIRSTVISIBLELINE, “These messages retrieve and set the line number of the first visible line in the Scintilla view. The first line in the document is numbered 0. The value is a visible line rather than a document line.” (emhasis added). The “document line” in Scintilla is the same thing that Notepad++ numbers in the line number column: it’s the real line, no wrapping. The “visible line” is affected by hiding lines and/or wrapped lines: if you have lines hidden in the document, that can decrease the visible line index relative to the document line number; if you have lines wrapped, that can increase the visible line index relative to the document line number. Scintilla has commands like SCI_VISIBLEFROMDOCLINE and SCI_DOCLINEFROMVISIBLE to help transform between the two concepts, and SCI_WRAPCOUNT will help you determine how many visible lines a single document line will become. If you want to turn word wrapping off, set your visible line, then reinstate word-wrapping, that’s fine; but the Scintilla messages provide other ways to allow you to correctly handle visible-line vs display-line.

I wasn’t able to add a PR or Issue to https://github.com/ezyuzin/NppAnotherMarkdown, but it turns out I was able to add an Issue to NPPMarkdownPanel here: https://github.com/mohzy83/NppMarkdownPanel/issues/192. What would be really good would be if the developers of these re-merged their plugins!

Now the plugin supports the Dark Mode by means of “SmartMath_Dark.udl.xml” (in addition to “SmartMath.udl.xml” which is the light one) and automatically applies either light or dark one. This is achieved by listening to NPPN_DARKMODECHANGED and requesting NPPM_ISDARKMODEENABLED to understand whether the dark UDL or the bright UDL to apply. A screenshot: [image: 1788983575005-055b172d-4091-4e16-a090-23e678758707-image.jpeg] Feel free to propose better colors if you are good in that :) The UDLs are here: https://github.com/d0vgan/npp-smart-math/tree/feature/powerful-calc/Notepad%2B%2B/userDefineLangs

@guy038 said: As for the first bug, I humbly apologize for the inconvenience caused : it’s my own fault. There’s no bug at all ! Maybe, maybe not. I forgot about a Notepad++ setting. I would guess that you have Settings | Preferences… | Editing 1 | Keep selection when right-click outside of selection checked. If I check that box, behavior is consistent with what you reported. Is that a bug? Scintilla normally responds to a right-click by clearing any selection and placing the caret at the position of the right-click, unless the right-click is within an existing selection. Notepad++ specifically captures right-clicks and overrides that behavior when that box is checked, so that right-click effectively behaves just like pressing the context menu key or Shift+F10, ignoring where you right-clicked and basing the context menu on the selection or caret location. I’m inclined to think that if someone has that box checked they probably know what to expect… but then, you didn’t. I haven’t yet investigated, but I suspect it would be possible to bypass that setting by capturing the actual screen location of the right-click, converting that to a character position, and acting accordingly. The question is, should I? To end, could you verify if you can reproduce the third bug or if I forgot something obvious ? Now, if you change the search string and try again to select the default Show option, NO change occurs at all. You need to first cancel the previous Show operation by running, within the Tools dialog, the Remove marks and bookmarks from active document option Then the Show feature applied to the modified search is correctly performed ! This isn’t really a bug, but a “feature” of questionable utility. Commands with default scope apply to marked text if there is any marked text, unless Settings | Marked Text | Default commands automatically search within marked text. is not checked. So most likely you see “No matches found in marked text.” at the bottom of the dialog when you attempt your second Show. If you used Show in Whole Document it would have worked. I agree, this is probably confusing. I didn’t want different default scope commands to behave differently, but this does seem like an exceptional case. I already have a checkbox for Allow default Mark command to Mark in Marked Text; I should probably have a similar Allow default Show command to Show in Marked Text, unchecked by default. Perhaps I should redesign this whole default scope concept. I just don’t know how to keep it flexible and convenient and user-friendly all at once. (I include a reasonably clean design, as in “dialog not so cluttered with buttons and options that your eyes hurt just looking at it” as part of user-friendly. Yet so is minimizing the “User Astonishment Factor”: as in, “Wow, I never expected that to happen!”)

@PeterJones said: If you’ve got steps that work for doing a local debug build, that would be helpful. > where cmake C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe > type .\build_gup.ps1 param ( [string]$Configuration = "Debug", [string]$Platform = "x64" ) if (-not $(Test-Path "${PSScriptRoot}\wingup\.git")) { git clone --single-branch https://github.com/notepad-plus-plus/wingup.git wingup } try { pushd "${PSScriptRoot}\wingup" $CmakeArchParam=$(if ("$Platform" -imatch "x86") {"Win32"} else {"$Platform"}) $LibPlatform=$(if ("$Platform" -imatch "Win32") {"x86"} else {"$Platform"}) cmake -S ".\curl" -B ".\curl\build\$LibPlatform" -A $CmakeArchParam ` -DBUILD_SHARED_LIBS=OFF ` -DCURL_STATIC_CRT=ON ` -DBUILD_CURL_EXE=OFF ` -DCURL_USE_SCHANNEL=ON ` -DCURL_USE_OPENSSL=OFF ` -DBUILD_TESTING=OFF ` -DUSE_LIBPSL=OFF ` -DCURL_USE_LIBPSL=OFF ` -DUSE_NGHTTP2=OFF ` -DUSE_LIBIDN2=OFF cmake --build ".\curl\build\$LibPlatform" --config $Configuration pushd vcproj msbuild GUP.sln /v:m /p:configuration=$Configuration /p:platform=$LibPlatform popd } catch { $_.InvocationInfo.PositionMessage; $_.Exception.Message } finally { popd } > powershell .\build_gup.ps1 Debug x86 # ...

@guy038 Hello @guy038, Thanks for this thorough test, and no, you didn’t do anything wrong. Your investigation uncovered two separate behaviors in the code: Binary Files: MultiReplace “Find in Files” currently skips binary files, while native N++ searches every file it lists. That accounts for most of the gap in your USB drive numbers. I’ll look at how to make this configurable and more transparent. UTF-16 Bug: There is indeed a bug in how “Find in Files” handles UTF-16 encodings compared to “Find in Docs” and “Replace in Files”. This most likely explains the missing files in your smaller Test folder too. Since the forum isn’t ideal for sharing files and tracking bug fixes, I have opened a GitHub issue for this here: https://github.com/daddel80/notepadpp-multireplace/issues/133 I would gladly take you up on your offer to share the E:\Test folder contents so I can verify the fix against them. Could you please attach that folder as a zip or provide a link in the GitHub issue? Thanks again for your time and for helping to polish the next release candidate!

@Afik-Gilboa said: both of them have the “run as administrator” unchecked. so any ideas why it keeps opening in admin mode? apparently everything running as administrator here, not sure why but it’s everything… I recognize the symptoms - you probably have turned off the Windows UAC completely somehow and at the same time the account, you are logged in, has the administrator rights (then everything launched will have the admin rights as default). Check your Registry for EnableLUA REG_DWORD 0x00000000 in: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] (click on Windows Start, start typing “Reg” there, click on the Registry Editor (System) app offered and navigate there to the hive path above) If there is that 0x00000000 (OFF), change it do 0x00000001 (ON) and restart your PC.

@PeterJones, many thanks to Your reply. This workaround works perfectly. I searched for this workaround (because I expected that anyone wouls have the same needs) but wasn’t successful - searching for a solution to a problem can be a frustrating experience if you don’t use the right search term(s) — which, of course, you don’t know yet at that stage…

@saintleningrad-prog said: Select text, or place the cursor inside a ^^…^^ tag, press Ctrl+Shift+E Just a head’s up: that’s the same default key combination that decodes HTML entities when HTML Tag is installed. Since plugin commands are mapped in alphabetical order, and the most recent mapping prevails, having both installed will silently block the EncTag’s plugin shortcut from functioning: [image: 1787355567929-enctags-v020-shortcut-conflict.png] One more thing: the text you are passing to the About message box (here) contains the literal Unicode character U+2013: EN DASH. Since the Unicode literal is inside a character string, the compiler interprets everything between "..." as if it were encoded in the operating system’s default, single-byte code page (usually Windows-1252 on English- or European-language PCs). When shown, the emdash becomes the string of nonsensical bytes \xe2\x80\x94: [image: 1787355726977-enctags-v020-mojibake.png] You just need to escape the Unicode literal, i.e., "Ctrl+Shift+E \u2013 ..."

@dcog989 Thanks for this - if you have any tweaks or updates you’ve made since this comment, let me know!

@Coises said: I expect that Version 0.6.5 will fix this. Noted, thanks again, and I’ll let him know — although he actually doesn’t typically use regex for his own purposes.

Since it’s essentially working at this point, I’ve renamed the Topic to “BETA” @mpheath , I have updated the README at https://github.com/pryrt/NppPlugin-HiddenLexers to enumerate available options I think I’ll be patient, and give the beta test a while longer, so won’t try to rush to release it before N++ v8.9.8’s PluginsAdmin list is finalized.

1.2.2 Syntax highlighting PowerShell Improved absolute, relative, quoted and unquoted paths colors [image: 1785402977913-paths.png] Improved variables interpolation colors [image: 1785402952228-interpolation.png] [image: 1785402954396-interpolation4.png] Added colors for expressions $(..), ${..} Added registry hives colors (HKLM, HKEY_LOCAL_MACHINE, …) Fixed syntax highlighting Fixed variables colors inside paths and quotes Fixed excessive colors of variables, keywords, and functions enclosed in quotes Fixed unexpected sc.. and vk.. colors in AutoHotkey code Disabled colors for variables inside single quotes ' ' (because single quotes prevents var. interpolation)

@Coises You’re welcome, and thank YOU for promptly creating the new version, and for your plugins in general to begin with! The new one lets me exit without incurring any dialog.

@arnaud-derette said: I does not work in the operator 2 list either (or may be i need to do something more than just put § there ?) Like I said, because you want the § to not have spaces, like in parent§.D, it won’t work for you. § in operators 2 will only work if you can have spaces around the §

@rdipardo thank you for pointing that out. I will check and do the needful.