Would it be less obnoxious if Edit | Copy and Cut were never disabled on the menu; that is, even when Enable Copy/Cut Line without selection is unchecked and nothing is selected, they would still be enabled: they just wouldn’t do anything? If I understand the code correctly, that would be an easy “fix” that wouldn’t be likely to cause unexpected side-effects.

I don’t like it that much but…If it fixes the larger problem it’s an acceptable trade-off.

The next least complicated way I can think of to fix this would be to create a “proxy” command that doesn’t appear on the menu, to which Ctrl+C/Ctrl+Insert can attached as a keyboard accelerator. Unlike the command that appears on the menu, the proxy command would never be disabled, allowing WM_COPY to be passed on to whatever control has focus. The same should be done for Ctrl+X/Shift+Delete, assuming I am correct that this also affects some docking dialogs (which I still haven’t verified).

I do like this better as a N++ user, because I don’t see it. But it probably complicates the code too much to be accepted.

Anyway @Coises, if you want to get involved and try to fix this, you’d have my thanks.

and I thought you recently mentioned that you used one of those external clipboard tools when it came up in another discussion

I do, but it is a pain to have to go there to get data, when I just had it. :-)

There is no undo for destroying the clipboard content (by trying to do Ctrl+v and mistakenly doing Ctrl+c).

I would have thought that Edit > Clipboard History would allow an undo for Ctrl+C – or that an external Clipboard-history tool would have that (and I thought you recently mentioned that you used one of those external clipboard tools when it came up in another discussion).

(Yes, E>CH isn’t a solution if you didn’t already have that panel open… but I would think the external clipboard tools were always running)

un-mess the whole debacle

Would it be less obnoxious if Edit | Copy and Cut were never disabled on the menu; that is, even when Enable Copy/Cut Line without selection is unchecked and nothing is selected, they would still be enabled: they just wouldn’t do anything?

If I understand the code correctly, that would be an easy “fix” that wouldn’t be likely to cause unexpected side-effects.

Edit to add: The next least complicated way I can think of to fix this would be to create a “proxy” command that doesn’t appear on the menu, to which Ctrl+C/Ctrl+Insert can attached as a keyboard accelerator. Unlike the command that appears on the menu, the proxy command would never be disabled, allowing WM_COPY to be passed on to whatever control has focus. The same should be done for Ctrl+X/Shift+Delete, assuming I am correct that this also affects some docking dialogs (which I still haven’t verified).

But thinking again of your variant - I am also plagued by your variant, so you are not the only one :-)

Often I want to hit Ctrl+C but press Ctrl+V which is even worse

Oddly, I don’t seem to be plagued by that variant.
Actually, I don’t think that is worse because you can usually Ctrl+z undo it.
There is no undo for destroying the clipboard content (by trying to do Ctrl+v and mistakenly doing Ctrl+c).

Hardly.

Sorry… but using the word “hate” in your post is a clear indication that it would be right over there.

looks more like a complaint topic to put into Boycott Notepad++

Hardly.

Why don’t you create a PR instead

No way am I going to try to un-mess the whole debacle, as mentioned by @Coises .
I’m more likely to write the script I mentioned to work around the problem.

And Alan, you are a skilled programmer from what I saw until now. Why don’t you create a PR instead of complaining? ;-)

t boggles my mind that no one has the same problem I do – fat fingering Ctrl+c when trying to hit Ctrl+v.

Yes, I have the same fat fingering problem. Often I want to hit Ctrl+C but press Ctrl+V which is even worse :-)

If this bug doesn’t get fixed soon, perhaps I’ll subclass Search results and listen for WM_KEYDOWN with Ctrl+c, and do my own copy-to-clipboard.

Not tested at this point, but I don’t think that will work. The message loop gets keyboard input first; before it even dispatches it to the focused window, TranslateAccelerator will recognize it as an accelerator for a disabled menu command and it won’t propagate any further.

I can guess that the reason it hasn’t been fixed yet is that it’s non-trivial to fix it without mucking about in places where it’s likely to cause something else to go wrong. Making Ctrl+C/X/V application-level accelerators made a lot of things more complicated. Hindsight makes one wish the desired changes to cut/copy/paste function had been accomplished by subclassing the Scintilla edit controls instead… but I doubt that choice will be reconsidered now.

It might be that few people have unchecked the option in question, so few people have noticed this.

It boggles my mind that no one has the same problem I do – fat fingering Ctrl+c when trying to hit Ctrl+v. If only “paste” had been made as Ctrl+p many years ago…

If this bug doesn’t get fixed soon, perhaps I’ll subclass Search results and listen for WM_KEYDOWN with Ctrl+c, and do my own copy-to-clipboard.

BUT…that causes a new problem: Ctrl+c will now no longer work in the Search results window. ARRRRGH! This is a bug, and I’ve REPORTED IT , but thus far (and through at least 1 release cycle) it hasn’t been fixed.

More fallout from changing cut/copy/paste to be Notepad++ commands instead of being local to whatever control has focus.

The keyboard shortcuts (and presumably toolbar buttons, though I don’t use a toolbar so I haven’t checked) fail because the main menu items are disabled.

Note that if you select some text in the edit window before you select something in the search results, the copy will work.

Presumably the same glitch occurs with at least some plugins with docking dialogs (unless they use NPPM_MODELESSDIALOG… remember that kerfuffle?). It might be that few people have unchecked the option in question, so few people have noticed this.

I left a comment on the issue in GitHub.