Notepad++ v8.7.6 released

donho

Notepad++ release 8.7.6 is available here:
https://notepad-plus-plus.org/news/v876-released/

Notepad++ release 8.7.6 change log:

Update to scintilla 5.5.3 & Lexilla 5.4.1. (Fix #10528, #15801, #15817, implement #15982)
Enhance performance of syntax highlighting for large files. (Fix #15952)
Make “Show close/pin button on each inactive tab” optional. (Fix #15912, #16035)
Add ShortcutMapper Multilingual ability, allowing the use of specific keys for non-en-US keyboards. (Fix #14395, #15966, #16071)
Fix vertical tab crashes when enabling/disabling the pin tab feature. (Fix #16033)
Fix crash when passing an invalid buffer with NPPM_SETUNTITLEDNAME. (Fix #15970)
Fix floating panels position resetting regression in multi-monitor configurations. (Fix #15498, #16077)
Fix incorrect “Replace all” behavior during the second replace in selection. (Fix #14897, #14624, #15992)
Fix backup file renaming bug for untitled tabs. (Fix #16043)
Enhance UX in “Find in file” action when the Directory field is empty. (Fix #16051)
Make the current line/position copyable in the Go to Line dialog. (Fix #15950)
GUI enhancement: hide right menu shortcuts on the fly. (Implement #16065)
Minor enhancements for JavaScript, CSS & HTML. (Fix #15821, #15825, #16036)

Auto-update will be triggered in one week if no critical issue found.

Ekopalypse

@donho
8.7.6 no longer forwards SC_MOD_BEFOREDELETE and SC_MOD_BEFOREINSERT. Will it stay that way?

donho

@Ekopalypse said in Notepad++ v8.7.6 released:

8.7.6 no longer forwards SC_MOD_BEFOREDELETE and SC_MOD_BEFOREINSERT. Will it stay that way?

Yes, I think. Does your plugin need these notifications?

Coises

@donho said in Notepad++ v8.7.6 released:

@Ekopalypse said in Notepad++ v8.7.6 released:

8.7.6 no longer forwards SC_MOD_BEFOREDELETE and SC_MOD_BEFOREINSERT. Will it stay that way?

Yes, I think. Does your plugin need these notifications?

Ugh. I missed that.

Columns++ uses SC_MOD_BEFOREDELETE but doesn’t strictly depend on it (I think I found there were conditions under which it wasn’t reliable); getting that message lets me handle the deletion to follow more efficiently.

I don’t recall the details now, but I remember that once the delete is done, I can’t get all the information I need to tell whether the deletion will affect the elastic tabstops layout. Capturing the before delete message makes a big difference when deleting single characters (Delete or Backspace key) in a large file — that will probably lag badly in large files without that message. I just hadn’t seen it yet.

Alan Kilborn

no longer forwards SC_MOD_BEFOREDELETE and SC_MOD_BEFOREINSERT

Maybe when the Release Candidate is published, such removals should be listed in a “beware plugin authors” (or some such) section.

Coises

@Alan-Kilborn said in Notepad++ v8.7.6 released:

no longer forwards SC_MOD_BEFOREDELETE and SC_MOD_BEFOREINSERT

Maybe when the Release Candidate is published, such removals should be listed in a “beware plugin authors” (or some such) section.

This could help for things that the author would be willing to revert (as he did the layout cache change). Perhaps (and I hope) he will revert this as well. But by the time a release candidate is finalized, it’s already too late to update plugins and get new versions into the plugin list, so it wouldn’t help with changes that will not be reverted.

We really need notice when potentially breaking changes become pull requests, so we can test and comment before they are accepted if we think they might adversely affect our plugins (and scramble to mitigate them if they are accepted anyway). I’m not sure how practical that is, though… it might be difficult for @donho to recognize a potentially breaking change. The structure of the Notepad++ plugin facility makes plugins potentially very powerful, but also potentially fragile.The Notepad++ messages are documented, but there are no documented “promises” (or boundaries) as to much of anything else, so it’s probably hard to tell what even constitutes a potentially breaking change.

Coises

@donho said in Notepad++ v8.7.6 released:

@Ekopalypse said in Notepad++ v8.7.6 released:

8.7.6 no longer forwards SC_MOD_BEFOREDELETE and SC_MOD_BEFOREINSERT. Will it stay that way?

Yes, I think. Does your plugin need these notifications?

Would it be possible and practical for Notepad++ to have a way for plugins to tell it, at startup, what Scintilla notifications they need, so Notepad++ can avoid disabling them? I don’t really know enough about why you sometimes choose to disable notifications we used to get, so I don’t claim to know if this idea makes any sense.

Mark Olson

@Coises said in Notepad++ v8.7.6 released:

Would it be possible and practical for Notepad++ to have a way for plugins to tell it, at startup, what Scintilla notifications they need, so Notepad++ can avoid disabling them?

This makes me wonder if maybe Notepad++ could do the reverse: have an NPPM_SCINOTIFICATIONENABLED(uint sciNotificationValue) message that plugins could send to NPP, where NPP would return 1 if sciNotificationValue is broadcasted to plugins, 0 if it is not broadcasted, and -1 if it is not a valid Scintilla Notification value.

The main downside I see of this hypothetical message is that Don Ho and others are somewhat likely to forget to update the function, and then it becomes worse than useless.

So I guess the question is: assuming NPPM_SCINOTIFICATIONENABLED always accurately reflected what messages are broadcasted, do you see it being enough of a benefit to you and other similarly situated people that it would be worth adding?

Coises

@Mark-Olson said in Notepad++ v8.7.6 released:

So I guess the question is: assuming NPPM_SCINOTIFICATIONENABLED always accurately reflected what messages are broadcasted, do you see it being enough of a benefit to you and other similarly situated people that it would be worth adding?

No.

I can really only speak for my own plugin. I had to figure out by trial and error what I could count on, because documentation isn’t all that precise. Experimenting with what I hope were realistic cases, I tried to figure out how I could maintain the desired display without lag. I found a way that works often enough. I chose a trade-off between complexity and results. I could make the implementation of elastic tabstops in Columns++ more responsive in more cases, but it wouldn’t improve the worst case, the typical case is already pretty good, and it would add a lot of complexity to the code and (in my estimation) make it more error-prone.

That trade-off depends on which messages I get. If I won’t be getting a notification before delete, I have to rethink that trade-off. I’ll probably conclude that I have to add the complex, error-prone code I’ve not yet written, because a rather common case will become laggy without it. It will take time, because it is not simple.

It wouldn’t be any help to find out dynamically what messages I will get. I need to know at design time what I can count on.

Ekopalypse

@donho said in Notepad++ v8.7.6 released:

Yes, I think. Does your plugin need these notifications?

Yes, both messages ensure that I get the correct position data that I need to calculate and convert.
I’m not saying it can’t be done with SC_MOD_DELETETEXT and SC_MOD_INSERTTEXT, but it’s definitely more difficult to get it right, at least in my case.

EDIT: By the way, this also applies to script plugins such as PythonScript etc., as these normally export all available functions.

Ekopalypse

Yes, I think it would be beneficial if plugin-related changes were announced with some lead time.
That could trigger a discussion about how the functionality to be removed could be realized in other ways, but that would also mean that the lead time would have to be a bit longer than a few days.
I’m thinking months, to be honest.

Possibly introducing a subscription model would be performance relevant, but that would also mean that currently running but no longer maintained plugins would then be obsolete. (which is also true when removing plugin related functionality)

Btw, fun fact, isn’t there a law in France against deliberate obsolescence :-D

donho

@Coises @Ekopalypse
The regression is due to this line:
#define MODEVENTMASK_ON SC_MOD_DELETETEXT | SC_MOD_INSERTTEXT | SC_PERFORMED_UNDO | SC_PERFORMED_REDO | SC_MOD_CHANGEINDICATOR
https://github.com/notepad-plus-plus/notepad-plus-plus/blob/master/PowerEditor/src/ScintillaComponent/ScintillaEditView.h#L97

The change is for enhancing large files’ syntax highlighting performance:
https://github.com/notepad-plus-plus/notepad-plus-plus/commit/de9ffd2ea8507d033f7f111d8b48762f7d3b9436

Since it’s for improving the performance & not all the plugins use such notifications, it won’t be reversed. Instead, I will add a new message NPPM_ADDSCINTILLANOTIFS for adding the notifications that plugins can add what they need, just after recieving NPPN_READY, for the next release:

extern "C" __declspec(dllexport) void beNotified(SCNotification *notifyCode)
{
	switch (notifyCode->nmhdr.code) 
	{

		case NPPN_READY:
		{
			::SendMessage(nppData._nppHandle, NPPM_ADDSCINTILLANOTIFS, 0, SC_MOD_DELETETEXT | SC_MOD_INSERTTEXT);
		}
		break;
...

What do you think?

Ekopalypse

@donho said in Notepad++ v8.7.6 released:

NPPM_ADDSCINTILLANOTIF

Does this mean that a plugin registers with this new message when starting for certain notifications?

donho

@Ekopalypse said in Notepad++ v8.7.6 released:

@donho said in Notepad++ v8.7.6 released:

NPPM_ADDSCINTILLANOTIF

Does this mean that a plugin registers with this new message when starting for certain notifications?

Yes

Ekopalypse

@donho

ok, so just to be sure I understand this correctly, in my case I would call

::SendMessage(nppData._nppHandle, NPPM_ADDSCINTILLANOTIFS, 0, SC_MOD_BEFOREDELETE | SC_MOD_BEFOREINSERT);

to reactivate these notifications?
And does this mean that these notifications are then globally available again? That is, if NppLspClient reactivates them, can PythonScript use them again? Or are they then only forwarded to the respective plugin?

donho

@Ekopalypse said in Notepad++ v8.7.6 released:

ok, so just to be sure I understand this correctly, in my case I would call

::SendMessage(nppData._nppHandle, NPPM_ADDSCINTILLANOTIFS, 0, SC_MOD_BEFOREDELETE | SC_MOD_BEFOREINSERT);
to reactivate these notifications?
And does this mean that these notifications are then globally available again?

Yes.

That is, if NppLspClient reactivates them, can PythonScript use them again?

Yes. But one plugin should not depend on other plugins’ registration.

Or are they then only forwarded to the respective plugin?

No.

By default, MODEVENTMASK_ON will contain the value SC_MOD_DELETETEXT | SC_MOD_INSERTTEXT | SC_PERFORMED_UNDO | SC_PERFORMED_REDO | SC_MOD_CHANGEINDICATOR

In the case that both Columns++ & NppLspClient are installed and both plugins have integrated NPPM_ADDSCINTILLANOTIFS message, and NppLspClient is loaded after Columns++:

And the latest registered value will be sent globally for all installed plugins.

Btw, fun fact, isn’t there a law in France against deliberate obsolescence :-D

I ensure you that it’s not deliberate obsolescence.
Notepad++'s code is biodegradable ;)

Ekopalypse

@donho said in Notepad++ v8.7.6 released:

Thank you, that sounds good to me.

Notepad++'s code is biodegradable ;)

Nice to know, I already have enough hazardous waste with my rusty code :-D

Coises

@donho said in Notepad++ v8.7.6 released:

The change is for enhancing large files’ syntax highlighting performance:
https://github.com/notepad-plus-plus/notepad-plus-plus/commit/de9ffd2ea8507d033f7f111d8b48762f7d3b9436

Since it’s for improving the performance & not all the plugins use such notifications, it won’t be reversed. Instead, I will add a new message NPPM_ADDSCINTILLANOTIFS for adding the notifications that plugins can add what they need, just after recieving NPPN_READY

[…]

What do you think?

I think it’s better than just removing functionality, though it could still break existing plugins if their authors are not active and able to keep up with changes. At least it would provide a quick way to restore compatibility when authors are available.

How will this work in connection with NPPN_GLOBALMODIFIED? Will SCN_MODIFIED messages requested by NPPM_ADDSCINTILLANOTIFS still be suppressed during Replace All operations?

Another thought has come to me, but the implications are unpleasant.

Columns++ only uses Scintilla notifications when implementing elastic tabstops, which can be enabled or disabled per document. By default, even after enabling it for one file, it is disabled when loading another file that is over 1000 KB or 5000 lines.

If excluding those notifications really does improve Notepad++ performance for large files, anyone with Columns++ installed would sacrifice that gain, even on files for which they were not using elastic tabstops (which is more likely to be the case with large files) — even those who never use that feature at all. Other plugins might face similar circumstances.

At present, I have no suggestion as to how that could be avoided in practice, though. For my plugin, since the loss of SC_MOD_BEFOREDELETE will cause degradation in responsiveness, rather than outright inaccurate behavior — and there may be another, more complex way to restore the responsiveness — I will have some design considerations to weigh with or without NPPM_ADDSCINTILLANOTIFS.

rdipardo

@Coises said in Notepad++ v8.7.6 released:

How will this work in connection with NPPN_GLOBALMODIFIED? Will SCN_MODIFIED messages requested by NPPM_ADDSCINTILLANOTIFS still be suppressed during Replace All operations?

What’s needed is a complelmentary set of *_GET_* and *_SET_* messages like Scintilla has for most properties.

Proper usage would be sending the *_GET_* message first, masking the return value for the desired flag(s), then restoring the flags by sending the *_SET_* message with the old value after the plugin is finished modifiying them.

PeterJones

I recommend that one of the plugin authors involved in this discussion create an issue at this point (referencing this topic, of course): now that the problem is defined, there appears to need to be more technical discussion as to how a fix might be implemented, and that’s better suited to an Issue than the Forum.

(The technical details might dissuade other users from posting other regressions in this discussion, and if the notification-discussion continues after someone does post another regression, their post may get lost in between posts about this issue.)