Notepad++ v8.6.1 Release

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.

astewart77

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

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.

It works fine:

SendMessage, 2650,,, Scintilla2, ahk_class Notepad++ ; SCI_GETSELECTIONEMPTY
msgbox % "empty = " ErrorLevel

It’s also cleaner for the Autohotkey coder because it avoids wiping out the current clipboard and a subsequent restore if needed.

Bro-Account

Bro-Account said:

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.

Can the existing Issue be re-opened or do I have to create a new one?

donho

@Bro-Account said in Notepad++ v8.6.1 Release:

    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.

Indeed.
Fixed in PR https://github.com/notepad-plus-plus/notepad-plus-plus/pull/14565
The fix will be included in the next release.

donho

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

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.

Thank you for your feedback.
Could you create an issue on GitHub if it’s not been created yet?

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

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?

No, it isn’t indeed.
I will see what I can do about it.

Coises

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

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

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

No.

Thank you for your feedback.

This is probably obvious, but in case it isn’t:

Removing the Ctrl+X/C/V shortcuts from their Edit commands does restore their function in JsonTools. When disableLineCopyCutDelete.xml has been added, Ctrl+X/C/V can be added to the corresponding Scintilla commands (thus restoring their function in the main editor) without impairing their function in JsonTools.

The underlying problem is that mapped shortcuts other than Scintilla commands are sent to Notepad++ when used in a non-modal dialog that doesn’t register with NPPM_MODELESSDIALOG. Apparently many plugins never did this, because the most commonly used shortcuts were Scintilla commands. Moving three very common shortcuts from Scintilla commands to Notepad++ accelerators changes that.

I don’t think there is a non-hacky solution that both allows for Cut/Copy/Paste to have functions not supported directly by Scintilla commands and doesn’t disrupt plugins that have (probably unknowingly) relied on this “loophole” in keystroke processing.

The simplest and least hacky solution is probably some form of the one @rdipardo suggests on GitHub, which amounts to forwarding WM_CUT/COPY/PASTE when it can be detected that IDM_CUT/COPY/PASTE has been called for a message to a window that isn’t an editor window.

donho

@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. Right-clicking and selecting “Paste” from the drop-down menu still works

Fixed in:
https://github.com/notepad-plus-plus/notepad-plus-plus/pull/14569

Sealex83

Hello everyone,
Happy New Year everyone.
Big problem after updating to latest version 8.6.1.
No more way to download files online.
Whether by the Upload arrow icons, or by the usual double click.
Currently I can only repatriate files by downloading via Filezilla.
(I have been a NPP++ user for over 15 years.
I even did tutorials on my forums.)
If you have any solutions, I’m interested.
To read to you

mkupper

@Sealex83 Please provide more detail to help others reproduce works and what does not work. The tips on reporting issues with Notepad++ article has a good checklist.

Alan Kilborn

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

Please provide more detail to help others reproduce works and what does not work

And remember, only critical issues for the 8.6.1 release should be reported in this thread. I guarantee that @Sealex83 's problem is NOT related to 8.6.1, despite the fact that he is convinced this is so. Non-critical 8.6.1 issues are best reported by creating a new issue on github; see this site’s FAQ for detail.

Sealex83

Hi friends,

I had no doubts about the Alan software.
But you answered well, and above all targeted my problem well.
This was not directly related to version 8.6.1.
But Sante doubts its update.
After investigation, I resolved the issue.
The software settings had been changed.
In particular FTP instead of SFTP, as well as port 21 instead of 22.
So everything is much better now.
Thank you for your answer.

Merci aussi mkupper