Notepad++ v8.6.2 Release Candidate

[Mark Olson]

I tested the 64bit 8.6.2 RC of the original posting.
I’ve tested and confirmed that a fresh install of JsonTools 6.1.1 from the plugins admin behaves as it did before the regressions of 8.6.1.

I’ve also tested and confirmed that Shift-DEL, Ctrl-INS and Shift-INS work as they should.

[Coises]

This is not necessarily a bug, and it’s not a problem for me, but it could represent a possible confusion for users on upgrade.

I have multiple versions of Notepad++ installed for testing, and I had been experimenting with the shortcut mapper and the xml file workaround. I am sorry, but I honestly do not remember the series of steps that got me to where I was before I installed 8.6.2 RC. I am reasonably certain that I left it in a state where 8.6.1 had both Ctrl+x/c/v and Shift/Ctrl+Ins/Del working in normal text. I installed 8.6.2 RC over 8.6.1. I then saw that the Ins/Del shortcuts did not work, and found, in Shortcut Mapper, Main menu tab, two instances of Cut, Copy and Paste, all shaded red, assigned to Ctrl+x/c/v (each combination twice).

Setting the second copy of each command to the Ins/Del combination made everything work as expected. So the only observation here is that there is at least some circumstance in which both copies of each Cut/Copy/Paste command get set to the left-hand shortcut.

[Michael Vincent]

@Coises said in Notepad++ v8.6.2 Release Candidate:

So the only observation here is that there is at least some circumstance in which both copies of each Cut/Copy/Paste command get set to the left-hand shortcut.

I see your confusion and am confused myself. We used to have SCI_CUT / COPY / PASTE on the Shortcut Mapper “Scintilla commands” tab which made it easy to see what we were mapping. Now with just 2 versions of “Cut / Copy / Paste” in the “Main Menu” section, I don’t know which one maps the direct Scintilla vs. the Notepad++ menu item.

See the confusion in the following diagram of 8.5.7 (before any of this), 8.6.2 clean and 8.6.2 executable copied over my current ‘config.xml’ and ‘shortcuts.xml’ and all my other current files:

Cheers.

[Coises]

@Coises said in Notepad++ v8.6.2 Release Candidate:

This is not necessarily a bug, and it’s not a problem for me, but it could represent a possible confusion for users on upgrade.

I have multiple versions of Notepad++ installed for testing, and I had been experimenting with the shortcut mapper and the xml file workaround. I am sorry, but I honestly do not remember the series of steps that got me to where I was before I installed 8.6.2 RC. I am reasonably certain that I left it in a state where 8.6.1 had both Ctrl+x/c/v and Shift/Ctrl+Ins/Del working in normal text. I installed 8.6.2 RC over 8.6.1. I then saw that the Ins/Del shortcuts did not work, and found, in Shortcut Mapper, Main menu tab, two instances of Cut, Copy and Paste, all shaded red, assigned to Ctrl+x/c/v (each combination twice).

Setting the second copy of each command to the Ins/Del combination made everything work as expected. So the only observation here is that there is at least some circumstance in which both copies of each Cut/Copy/Paste command get set to the left-hand shortcut.

Oh, my… now we are in bug territory. After closing v8.6.2 and opening again, now I have this:

and of course, now Ctrl+x/c/v don’t work.

[Michael Vincent]

@Coises said in Notepad++ v8.6.2 Release Candidate:

Oh, my… now we are in bug territory.

Seems you need to go into your ‘shortcuts.xml’ file and delete all references to:

        <Shortcut id="42001" ...
        <Shortcut id="42002" ...
        <Shortcut id="42005" ...

and then it should work as fresh out-of-the-box 8.6.2. Though not sure what happens if you try to remap one of them, as the both (Cut/Cut or Copy/Copy, etc.) have the same shortcut ID it seems. Shouldn’t they be different ID for the Notepad++ menu item and for the Scintilla direct SCI_CUT, SCI_COPY …

Cheers.

[Coises]

It appears that if any of the Edit | Cut/Copy/Paste commands are changed in Shortcut Mapper, once Notepad++ is closed and opened again, both copies of the affected command(s) is/are set to the same value. This includes clearing the commands. The only way to restore the default setting is to modify or delete shortcuts.xml.

It appears that both entries have been assigned the same id number, and this must confuse the process which maps the shortcuts.xml to the internal table.

I’ve reported this as Issue #14585.

[Coises]

@Michael-Vincent said in Notepad++ v8.6.2 Release Candidate:

Now with just 2 versions of “Cut / Copy / Paste” in the “Main Menu” section, I don’t know which one maps the direct Scintilla vs. the Notepad++ menu item.

They both map to the menu item.

Clearly, this hack was introduced because, unlike Scintilla commands, Main menu shortcuts don’t allow multiple shortcuts for the same command. It apparently has an unforeseen implication.

[Michael Vincent]

@Coises said in Notepad++ v8.6.2 Release Candidate:

Clearly, this hack was introduced because, unlike Scintilla commands, Main menu shortcuts don’t allow multiple shortcuts for the same command. It apparently has an unforeseen implication.

I think I’m understanding now.

I’m still fuzzy on what plugins need to do to start receiving CTRL-C, CTRL-V commands again. For example, the fork of the Explorer plugin I use stopped receiving CTRL-C, CTRL-V commands with the update to 8.6 and even with 8.6.2 - it still does not work. However, the Plugin Admin version of Explorer seems to work OK to copy files with CTRL-C, CTRL-V commands in 8.6.2.

I’d like to patch / PR the fork version, but not sure where to start. In trying to follow this in the community and on GitHub issues and PRs, I think it has something to do with NPPM_MODELESSDIALOG.

Cheers.

[Coises]

@Michael-Vincent said in Notepad++ v8.6.2 Release Candidate:

I’m still fuzzy on what plugins need to do to start receiving CTRL-C, CTRL-V commands again.

The problem arose because the desired behavior for Cut, Copy and Paste is no longer the same as the behavior of the corresponding Scintilla commands, so they were moved to menu commands.

The difficulty with this is that shortcuts for menu commands are captured as part of something called the “message loop” (this is standard Windows best practice) and sent to the routines that process those menu commands, unless something special is done to prevent that. (See IsDialogMessage.) “Modal” dialogs — the ones that don’t let you go back to the main window until you close them — have their own message loop, so this doesn’t affect them. Non-modal windows — ones that you can leave open and still switch back to the main editor — share the main program’s message loop. The NPPM_MODELESSDIALOG message was created so plugins can tell Notepad++ keystrokes entered while focus is in those windows should skip menu shortcut translation.

So all of this didn’t affect plugins that either had no non-modal dialogs or that registered their non-modal dialogs using NPPM_MODELESSDIALOG. However, it seems there are many plugins that have non-modal dialogs and don’t use NPPM_MODELESSDIALOG. For these plugins, menu command shortcuts always did the menu command instead of going to the dialog. When some very common shortcuts — the ones for Cut, Copy and Paste — became menu shortcuts, this changed from something few people noticed to something widely troublesome.

One solution would have been to find a way to detect these plugin windows without NPPM_MODELESSDIALOG. That would cause a different change in plugin behavior, though, and Don chose — probably wisely — not to go that route.

Instead, what Notepad++ v8.6.2 RC does is detect — just for Cut, Copy and Paste — when the menu command has been invoked but focus is not in the active Scintilla control. In those cases, Notepad++ forwards a WM_CUT, WM_COPY or WM_PASTE message to window that was the destination of the original message.

Most of the time that should work, since common edit controls translate Ctrl+x/c/v to those messages. However, should the plugin code be looking for the actual keyboard message, and not the WM_CUT/COPY/PASTE translation, it will still fail unless it registers with NPPM_MODELESSDIALOG (which still skips menu shortcut processing entirely).

[László Botka]

@Michael-Vincent said in Notepad++ v8.6.2 Release Candidate:

<Shortcut id=“42001” …
<Shortcut id=“42002” …
<Shortcut id=“42005” …

I tried the portable version, and deleted the 3 lines.

I Cleared the Cut Ctrl-X shortcut, because I have a Ctrl-X macro, both Ctrl-X and Shift-Del works fine.
However If I reload npp, in the shortcut mapper the Cut Shift-Del entry is cleared too, and so Shift-Del doesn’t work.

[donho]

@Coises said in Notepad++ v8.6.2 Release Candidate:

It appears that if any of the Edit | Cut/Copy/Paste commands are changed in Shortcut Mapper, once Notepad++ is closed and opened again, both copies of the affected command(s) is/are set to the same value. This includes clearing the commands. The only way to restore the default setting is to modify or delete shortcuts.xml.

It appears that both entries have been assigned the same id number, and this must confuse the process which maps the shortcuts.xml to the internal table.

I’ve reported this as Issue #14585 .

Fixed in https://github.com/notepad-plus-plus/notepad-plus-plus/pull/14588
Could you check the fix please?

[Coises]

@donho said in Notepad++ v8.6.2 Release Candidate:

Fixed in https://github.com/notepad-plus-plus/notepad-plus-plus/pull/14588
Could you check the fix please?

I replaced the exe in 8.6.2 RC with the one in MSVC.x64.Release from the artifacts dropdown on the Checks tab — I think that’s the right way to test — and I was unable to get the Shortcut Mapper to misbehave. So that’s good.

There is still a corner case for updating — I really don’t know if I would call it a “bug,” since it requires that the user has done something rather odd. I tried setting Shift+DEL to be a shortcut for File|Move to Recycle Bin in 8.6.1. Upon then launching 8.6.2 RC + pull 14588, the shortcut is duplicated as both its previous assignment and Edit|Cut.

[László Botka]

I left “Cut 1” as Shift-Del and deleted “Cut 2” Ctrl-X.

So Shift-Del deletes the line and Ctrl-X executes my macro, even after reloading.

So this works fine for me, I don’t see other problem here.

[Andi Kiissel]

@Coises said in Notepad++ v8.6.2 Release Candidate:

…it requires that the user has done something rather odd…

Perhaps not very rarely - i have Shift+DEL reassigned to a script and don’t want it to affect the clipboard.
BTW, I’ve reassigned Ctrl+C and Ctrl+X too.

[donho]

@Coises said in Notepad++ v8.6.2 Release Candidate:

There is still a corner case for updating — I really don’t know if I would call it a “bug,” since it requires that the user has done something rather odd. I tried setting Shift+DEL to be a shortcut for File|Move to Recycle Bin in 8.6.1. Upon then launching 8.6.2 RC + pull 14588, the shortcut is duplicated as both its previous assignment and Edit|Cut.

If in your old shortcuts.xml the Shift-DEL is assigned already Move to Recycle Bin command and you keep the same shortcuts.xml with the fixed binary, then Shortcut Mapper should show the conflict of Shift-DEL for Cut & Move to Recycle Bin commands.

“Corner case” due to the update of Notepad++ behaviour changement why not, but it’s not a bug definitely.

[donho]

@Coises said in Notepad++ v8.6.2 Release Candidate:

One solution would have been to find a way to detect these plugin windows without NPPM_MODELESSDIALOG. That would cause a different change in plugin behavior, though, and Don chose — probably wisely — not to go that route.

I don’t think there is any other solution exists - that’s why NPPM_MODELESSDIALOG is there for this purpose.

But if you have the solution for it, you’re very welcome to do a PR. I’ll consider it for sure.

[donho]

FYI: v8.6.2 RC binaries is updated.
This update contains the fix https://github.com/notepad-plus-plus/notepad-plus-plus/commit/75ae73c17333e6a83ce84c11ef052b6e2e5693ca.

[Coises]

@donho said in Notepad++ v8.6.2 Release Candidate:

I don’t think there is any other solution exists - that’s why NPPM_MODELESSDIALOG is there for this purpose.

But if you have the solution for it, you’re very welcome to do a PR. I’ll consider it for sure.

This GitHub message from plugin author @Mark-Olson led me to reconsider the idea. It would cause a change in behavior for plugins that currently have non-modal dialogs (including docking dialogs) and do not send NPPM_MODELESSDIALOG messages; it seems it is not safe to assume that change would always be welcome.

I described my “solution” here; but I won’t make a pull request, because I no longer think it is a good idea.