Notepad++ v8.6.1 Release

donho

Notepad++ v8.6.1 Release is available here:
https://notepad-plus-plus.org/news/v861-released/

Notepad++ v8.6.1 Change log:

Updated to Scintilla 5.4.1 & Lexilla 5.3.0. (Implement #14375)
~~Fix a regression: the position in the previous session is now restored correctly in cloned document. (Fix #14164)~~
Fix a regression: customized extension in Style Configurator is now saved correctly. (Fix #14437)
Add an ability (disableLineCopyCutDelete.xml) to disable line copy/cut/delete when no selection is made and add back Shift-DEL & Ctrl-INS shortcuts. (Fix #14470, ref, ref))
Add an ability (noColumnToMultiSelect.xml) to disable column mode to multi-select mode. (Fix #14464, ref)
Fix deleting in column mode also delete an unexpected EOL. (Fix #14426)
Fix hidden results of long lines for Search results with “Find in…” commands. (Fix #12023)
Enhance Search-results by showing search options for “Find in…” commands. (Fix #14306)
Fix an issue: replacements are no longer duplicated (the 2nd time in cloned document) for “Replace in Opened Docs”. (Fix #14505)
Fix a regression to make F3 & Shift-F3 work again in Incremental Search. (Fix #14503)
Add document tab navigation commands: “First tab” & “Last tab”. (Fix #14416)
Add document tab commands: “Move to Start” & “Move to End” commands. (Fix #9525, #13982)
3 RTL new abilities: RTL per document, RTL per document remembered across the sessions & new attribute editZoneRTL=“no” in RTL localization files. (Fix #9665, #9950, #14385)
Enhance the “-loadingTime” command line parameter. (Fix #14472)
Enhance the performance: disable undo collection while loading a file. (Fix #14455)
Sort language list in the Preferences dialog. (Fix #14245)
Fix a visual glitch that occurred during multi-paste. (Fix #14410)
Fix confusing memory allocation error message. (Fix #14418)
Fix python wrong decorator attribute color. (Fix #5894)
Fix file status in “other view” is not detected. (Fix #14225)
Fix dropped file being opened in the wrong view. (Fix #14354)

Mark Olson

There seems to be a weird bug where you can’t use Ctrl+V to paste text into the text fields of forms for certain plugins. Right-clicking and selecting “Paste” from the drop-down menu still works.

As far as I know, this only affects Windows Forms (made by plugins based off the C# plugin template), because of the following pattern I observed:

JsonTools 6.1.1, a C# plugin, has this bug.
NavigateTo 2.7, also a C# plugin, has this bug.
Columns++ 1.0.2, a C++ plugin, does not appear to have this bug.
ComparePlus 1.1, a C++ plugin, does not appear to have this bug.

I went back to v8.6, and confirmed that this was not a problem in that version.

I observed this bug in both the 64bit and 32bit versions of 8.6.1, but I haven’t done all of the above tests in the 32bit version (I reproduced it for JsonTools only).

Debug info:

Notepad++ v8.6.1   (64-bit)
Build time : Jan  4 2024 - 05:01:52
Path : C:\Program Files\Notepad++ 8p6p1\notepad++.exe
Command Line : 
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
OS Name : Windows 10 Home (64-bit)
OS Version : 22H2
OS Build : 19045.3803
Current ANSI codepage : 1252
Plugins : 
    ColumnsPlusPlus (1.0.2)
    ComparePlus (1.1)
    JsonTools (6.1.1)
    mimeTools (3)
    NavigateTo (2.7)
    NppConverter (4.5)
    NppExport (0.4)

Mark Olson

@Mark-Olson

There seems to be a weird bug where you can’t use Ctrl+V to paste text into the text fields of forms for certain plugins.

OK, so I was able to partially fix this issue in 8.6.1 (as in, Ctrl+V now pastes text, but it does it on keyup, rather than on keydown as is normal).

I’m pasting the code that any plugin will need to include to fix this issue the same way I did:

In any Windows Forms file, add the following function, and then add a KeyUp handler calling it to every textbox and combobox in every form:

        /// <summary>
        /// fix issue where Ctrl+V doesn't paste text into textboxes on Notepad++ 8.6.1<br></br>
        /// this is a no-op for versions of Notepad++ before 8.6.1
        /// </summary>
        /// <param name="e"></param>
        public static void PasteIfCtrlV(object sender, KeyEventArgs e)
        {
            if (e.Control && e.KeyCode == Keys.V &&
                /* TODO: INSERT CHECK IF Notepad++ version is >= 8.6.1 */
                && Clipboard.ContainsText())
            {
                string pastedText = Clipboard.GetText();
                if (sender is TextBox tb)
                    tb.SelectedText = pastedText;
                else if (sender is ComboBox cb)
                    cb.SelectedText = pastedText;
            }
        }

Pay careful attention to the commented TODO in the above function! You will need to add a check for whether the Notepad++ version is greater than or equal to 8.6.1, so that the text is only pasted in cases where Ctrl+V does not work normally.

To see how to check the Notepad++ version, look at the NppVersionString function in Npp.cs, which references the GetNppVersion function in NotepadPPGateway.cs

Bro-Account

donho said:

Fix a regression: the position in the previous session is now restored correctly in cloned document. (Fix [#14164])

Unfortunately this seems to be still not fixed for me in 8.6.1.

Alan Kilborn

@Mark-Olson said:

so I was able to partially fix this issue in 8.6.1

Note to interested readers that Mark did NOT fix anything in 8.6.1 itself (as implied here), he adapted a plugin response to a change new to N++ 8.6.1. That’s fine (I suppose), but let’s be clear about it.

(as in, Ctrl+V now pastes text, but it does it on keyup, rather than on keydown as is normal).

If “keydown as is normal” is true, isn’t the better path forward to call it a Notepad++ regression and wait for the bug to be fixed, rather than forcing some unknown number of plugins to adapt to a “not normal” change?

rdipardo

@Alan-Kilborn said in Notepad++ v8.6.1 Release:

isn’t the better path forward to call it a Notepad++ regression and wait for the bug to be fixed . . .?

Indeed, this was apparently caused by this commit, after which SCI_PASTE is no longer mapped to Ctrl+V, but to Shift+INS instead.

donho

@Mark-Olson said in Notepad++ v8.6.1 Release:

As far as I know, this only affects Windows Forms (made by plugins based off the C# plugin template ), because of the following pattern I observed:

Does the following link solve your problem?
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14557

Coises

@Mark-Olson said in Notepad++ v8.6.1 Release:

As far as I know, this only affects Windows Forms (made by plugins based off the C# plugin template ), because of the following pattern I observed:
JsonTools 6.1.1 , a C# plugin, has this bug.
NavigateTo 2.7 , also a C# plugin, has this bug.
Columns++ 1.0.2 , a C++ plugin, does not appear to have this bug.
ComparePlus 1.1 , a C++ plugin, does not appear to have this bug.

I note that JsonTools shows this behavior in the Json Tree Viewer window, but not in the Settings dialog.

The Tree Viewer in JsonTools and the NavigateTo dialog are both dockable dialogs. The Settings dialog in JsonTools is modal and non-dockable. Columns++ has both modal and non-modal dialogs, but none are dockable. I haven’t looked at ComparePlus in depth, but it does not appear to have any dockable dialogs.

I think it’s possible that it’s dockable dialogs, not C# forms, that trigger the problem.

rdipardo

@Coises said in Notepad++ v8.6.1 Release:

The Tree Viewer in JsonTools and the NavigateTo dialog are both dockable dialogs. The Settings dialog in JsonTools is modal and non-dockable. Columns++ has both modal and non-modal dialogs, but none are dockable.

Dockable dialogs are owned by the Notepad++ window, i.e., they’re constructed with a handle to the application window (not to be confused with the editor handle, which belongs to Scintilla). Modal dialogs typically have no owner (handle = 0); “non-modal” (floating?) dialogs may have one or the other.

The owning window receives the key event first. My guess is that whatever N++ now does with CTR+V is not propagated to the (docked) child windows. I tried Shift+INS and it works for every plugin with an edit control, whether native or delegated to the .NET runtime. A GitHub user explains that Shift+INS is a system-defined key combo, which ought to bypass both N++ and Scintilla’s key handlers and “just work” in all cases.

In the (unlikely) event there’s a corrective intervention upstream, it would involve some manner of broadcasting Ctrl+V to the child windows, the way Scintilla (implicitly?) did when Ctrl+V was mapped to SCI_PASTE. In other words, restore Scintilla’s former role in the key event life cycle.

Coises

Ctrl+drag starting within an existing selection does not copy, as in previous versions and most edit controls.

See Issue #14561 for details and workaround.

Edit: Ugh. Apparently this is a Scintilla change, as explained in a comment to the issue.

It seems Notepad++ and Scintilla are in agreement: nothing is too standard, familiar and time-honored to be broken if it improves multiple selection.

Mark Olson

@Coises said in Notepad++ v8.6.1 Release:

I think it’s possible that it’s dockable dialogs, not C# forms, that trigger the problem.

No, it’s more complicated than that.

JsonTools has the grepper form and the sort form, neither of which is dockable or spawned from a dockable dialog, and those both have the Ctrl+V issue.

Weirdly enough, the CSVLint plugin, which is also C#, does not appear to have this issue.

@donho

Does the following link solve your problem?
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14557

No.

I added an empty file named disableLineCopyCutDelete.xml to my %Appdata%/Notepad++ directory as instructed in your post.
I then rebuilt JsonTools with the code that fixed the issue commented out, to isolate whether your proposed fix had any effect.
Ctrl+V still did not work in any of my forms, dockable or otherwise.

@rdipardo

I tried Shift+INS and it works for every plugin with an edit control, whether native or delegated to the .NET runtime

I tested this, and it does indeed work even when Ctrl+V doesn’t. If this issue isn’t fixed, that’s probably what I will advise my users to do.

Coises

@rdipardo said in Notepad++ v8.6.1 Release:

The owning window receives the key event first.

Both the modal and non-modal dialogs in Columns++ are created with the Notepad++ window as the owner. I don’t think that can be the problem. It’s not the owning window, but the message loop, that receives and dispatches keystroke messages.

What does matter is that my non-modal dialog calls NPPM_MODELESSDIALOG when it opens and closes. This adds it to the table used to call IsDialogMessage in this code. Without that, keyboard navigation and underlined dialog accelerators don’t work as expected.

When the JsonTools panel is open and the focus is in the input area, Ctrl+f opens the Notepad++ find dialog. When the (non-modal) Search dialog in Columns++ is open and focused, Ctrl+f doesn’t do anything.

So I’m guessing these dockable dialogs are not registered using NPPM_MODELESSDIALOG and hence are subject to the main Notepad++ accelerator table. That changed, I believe, to support the new cut/copy/paste without selection behavior, which I would guess is why the dockable dialogs are seeing something different than before.

Coises

@Mark-Olson said in Notepad++ v8.6.1 Release:

JsonTools has the grepper form and the sort form , neither of which is dockable or spawned from a dockable dialog, and those both have the Ctrl+V issue.

They appear to be non-modal dialogs opened without setting the Notepad++ window as parent and without sending NPPM_MODELESSDIALOG messages.

As per my message above, I suspect not using NPPM_MODELESSDIALOG is the common factor; but I haven’t worked with dockable dialogs and don’t know whether they can, should or usually do register as modeless dialogs.

Coises

@Mark-Olson said in Notepad++ v8.6.1 Release:

Weirdly enough, the CSVLint plugin, which is also C#, does not appear to have this issue.

The ConvertData and Settings dialogs don’t (just as your Settings dialog doesn’t) because they are modal. Modal dialogs have their own message loop and don’t depend on the calling program’s loop, so Notepad++’s changes in how keystrokes are processed don’t affect them.

The CSV Lint window (dockable) does show this behavior (Shift+Insert pastes, Ctrl+V does nothing) in the left-hand pane. (I’m also finding that soon after undocking that window, Notepad++ freeezes… I don’t normally have that plugin installed, and I haven’t yet tested whether it’s an interaction with some other plugin.)

rdipardo

@Coises said in Notepad++ v8.6.1 Release:

I’m also finding that soon after undocking that window, Notepad++ freeezes…

Known issue, though one with a relatively trivial fix, i.e.,

intptr_t attributes = ::GetWindowLongPtr(wincontrol.Handle, GWL_EXSTYLE);
::SetWindowLongPtr(wincontrol.Handle, GWL_EXSTYLE, attributes | WS_EX_CONTROLPARENT);

PeterJones

@donho,

Making everyone who uses plugin dialogs or docked windows put in a zero byte config file to undo the recent problematic new feature seems the wrong way around to me.

As much as the magic copy/cut/delete is a cool way to imitate VS, is the cool new feature really worth the problems it has caused in v8.6 and v8.6.1?

As @Alan-Kilborn has suggested here and at other times, if it’s implemented so that the magic copy/cut are separate menu entries, with the default shortcuts set to the old entries (ie, v8.5.8), then people will get what they expect by default, but have the ability to decide for themselves to change the shortcut to access the magic version: that gives everyone what they want, without causing problems with the standard installation.

rdipardo

I can confirm that Object Pascal components are affected, too. I built my template plugin for the Delphi and Free Pascal platforms. In both cases the TMemo only responds to Shift+INS, whether or not the magic XML file was present (which was also my observation with the .NET plugins mentioned earlier).

As further evidence that modal forms are immune, F# Interactive’s configuration menu functions just like before.

It’s obvious by now that any child window with an edit control will inherit N++'s own non-responsiveness to Ctrl+V. The choice of programming language really has nothing to do with it.

Coises

@donho
@rdipardo
@Mark-Olson said in Notepad++ v8.6.1 Release:

There seems to be a weird bug where you can’t use Ctrl+V to paste text into the text fields of forms for certain plugins.

I’m not familiar with C# or with dockable dialogs. However, I was able to reproduce the Ctrl+V failure in the Search (non-modal) dialog of my (C++) Columns++ plugin by commenting out the lines that send NPPM_MODELESSDIALOG messages.

I believe the entire “problem” arises from the failure to send those messages. (Searching the git repositories of some of the plugins cited as having this problem suggests that they do not send NPPM_MODELESSDIALOG messages.)

Can anyone demonstrate a case of this happening in a modal dialog, or in a non-modal dialog that has been properly registered using NPPM_MODELESSDIALOG?

@PeterJones

Making everyone who uses plugin dialogs or docked windows put in a zero byte config file

I’m not crazy about some of the recent changes either, but in this case I think it’s more like “making plugin authors code their plugins correctly.” NPPM_MODELESSDIALOG goes back at least as far as version 5.6.7, so it’s not like this is a new thing.

Edit to add:

One more thing of note is that a user of previous versions of Notepad++ who assigned Ctrl+V to something other than ~~the default~~ a Scintilla command would also experience failure to paste in non-modal dialogs that don’t register with NPPM_MODELESSDIALOG. (Tested with 8.5.8 and 8.6, using Columns++/Search as the test with registration and JsonTools/Open JSON tree viewer as the test without registration.)

Oh, and all this applies to Ctrl+x and Ctrl+c, too.

Even if separate menu items were created, a user who wanted Ctrl+x/c/v to perform the new, extended functions in the Scintilla control would have to give up having them work at all in non-modal dialogs that don’t register using NPPM_MODELESSDIALOG. The solution is to fix the plugins.

PeterJones

@Coises said in Notepad++ v8.6.1 Release:

in this case I think it’s more like “making plugin authors code their plugins correctly.”

That’s only a part of the picture. If the final solution from Notepad++ is that “plugins must be edited”, these three things are true, none of which are pleasant to have true:

Notepad++ communicates to users that their use of and desire for plugins is unimportant, and that they either need to stop using any problematic plugin until they’ve been updated (and then re-submitted to the plugins admin and included in some random future release), or they need to turn off auto-update checks and stay with an older version of Notepad++ so that they can use the plugins they have grown accustomed to – and either way, the users’ opinions of Notepad++ and its ecosystem are soured, possibly to the point of stopping using Notepad++.
Notepad++ communicates to plugin developers that it doesn’t care about plugin developers, and is willing to implement breaking changes in the behavioral contract (explicit and implied) between Notepad++ and plugins (which includes but is not limited to the API) without any notice, and is willing to sour people’s opinions of a given plugin because Notepad++ makes a change which unexpectedly breaks plugins, and then lays the blame on the plugin developer for not being able to foresee the design decisions that they made given that it worked under the current version, years of existing behavior giving weight to the conclusion that their decisions were reasonable and correct. This could quite easily chase away plugin developers who decide that they don’t want to spend their time supporting and developing plugins when they cannot guess when a potentially-breaking change might be made.
It ignores the other issues involved in the new magic copy/cut, including the fact that the implementation decisions made for v8.6 necessitated the zero-byte config file disableLineCopyCutDelete.xml be added to v8.6.1 in order for people to turn off behavior which did not meet reasonable user expectation.

So yes, plugin authors should definitely fix their plugins now that they know about the true implications of the NPPM_MODELESSDIALOG message, but the only way to undo this major regression in a reasonable amount of time is for Notepad++ to take on some of the blame and responsibility, and do a v8.6.2 release as soon as possible to fix this. The longer this situation lasts, the more users, and plugin developers, will decide that Notepad++ and its ecosystem isn’t worth the hassle.

Addenda: If I sound a bit strong in this post, its because I care deeply for Notepad++: I’ve been a user since circa 2005 – the vast majority of Notepad++'s 20 years, and a significant portion of my adult computing life – and have been a proponent of Notepad++ since I first tried it, and I have been a major contributor to this Community since I joined 8 years ago. So at this point, I am emotionally and psychologically invested in the success of Notepad++. And I think that how Don chooses to handle this issue is going to be a huge part of deciding (or at the very least, an indicator of) whether Notepad++ will continue to be a viable editor in the next few years, let alone in the next 20. And I’d really like to be able to continue using Notepad++ for the next 20 years if possible.

Coises

@PeterJones said in Notepad++ v8.6.1 Release:

That’s only a part of the picture.

Despite some of what I’ve written… I agree with you. Breaking plugins is never good; it alienates users and plugin authors.

As I just recently suggested, a sensible compromise would be to use Scintilla functions for this. That would mean losing cut-without-selection. Copy and copy-whole-line-when-nothing-is-selected would be available, and paste would take care of itself. Whichever is the default for copy, users could use the Scintilla commands tab of the Shortcut mapper dialog to change to the other one.

Because Scintilla shortcuts are translated by Scintilla, and not by the message loop, the behavior of plugins would return to the pre-8.6.1 status quo.

The only other real-life problem I’ve seen described is that a couple people using AutoHotKey depended on clearing the clipboard, then sending Ctrl+c to Notepad++ and checking for an empty clipboard to determine whether anything is selected. I don’t use AutoHotKey, but I found what appears to be a more reliable way to test for an empty selection. I don’t know if anyone has tried it.

There is still, perhaps, a question which function should be Copy on the Edit menu — SCI_COPY or SCI_COPYALLOWLINE — but it doesn’t seem like the overall impact could be that big… if we could give up the non-Scintilla “CUTALLOWLINE” function, thus letting everything else be handled by Scintilla.