New API to fix eventual regression regarding SCN_MODIFIED for some plugins

Lycan Thrope

@Eric-Pendergrass,
What it seems you’re experiencing is mostly likely the Session Snapshot and periodic backup feature working as designed. This screenshot shows you the default setup:

You can change the time the auto backup occurs or just unselect it, but I suggest you point it somewhere other than your OneDrive directory, because that will include network traffic issues to complete the updates, and that many times is ludicrous for this situation. Better you point it to your local drive as shown in my setup. Hopefully you don’t have a 2 billion size file, or multiples, as that also would explain the horrendous delay. Less is more.

mkupper

@Eric-Pendergrass said in New API to fix eventual regression regarding SCN_MODIFIED for some plugins:

Reach out to me if anyone needs help reproducing this bug or wants to collect any logs from me

It definitely looks like something that we should attempt to reproduce. Let’s start with your debug info. From Notepad++ click on the ? that is at the top-right of the menu bar at the top of Notepad++ and then select Debug Info.... Click the [Copy debug info into clipboard] button and then paste the results into this forum thread. Next, select the text you just added to the forum’s message box and click the </> button from the forum toolbar that’s just above the message box. This will bracket the selected text with ``` lines.

I believe the main value will be the list of plugins you are using but it’s best to include the full debug info dump.

rdipardo

@mkupper said in New API to fix eventual regression regarding SCN_MODIFIED for some plugins:

It definitely looks like something that we should attempt to reproduce.

I doubt that. The only way a plugin could misuse SCN_MODIFIED would be to program a callback that caused another SCN_MODIFIED event to fire, recursively. Like, say the modificationType field of the scn notification header contained the SC_MOD_DELETETEXT flag, and the callback took the header’s text field and put it back into the document with ::SendMessage(scn->nmhdr.idFrom, SCI_INSERTTEXT, scn->position, scn->text), or something equally stupid.

In other words, a plugin would have to deliberately behave like malware to create such a performance-degrading feedback loop; changing the default event mask as happened in v8.7.7 would not have that effect.

mkupper

@rdipardo I have a bit more than casual interest in what @Eric-Pendergrass reported as I too have seen some unexpected behavior. A couple of weeks ago I noticed that Npp seemed to be writing to disk every 7 seconds despite Notepad++ being idle/unused at the time. However, by the time I had a chance to dig into what was happening the problem went away.

Luckily, it’s happening again to me right now and so I was able to track down what is happening but don’t understand why. I have also confirmed that the issue is not a recent regression and is not related to the SCN_MODIFIED changes. We likely should shift this topic drift to a new forum thread.

However, Notepad++'s behavior still bothers me or at least it is unexpected. What I am seeing is that if a file/tab has been dirtied since I started Notepad++.exe that Notepad++ starts writing that file to the backup folder every 7 seconds when it is the active tab. This occurs with npp versions v8.7.5, v8.7.6, and v8.7.7. This still occurs when Notepad++.exe is started with -noPlugin

@Lycan-Thrope says this is “by design” but it still surprises me. Why does Notepad++ need to flush the current tab’s file to disk every 7 seconds even when Notepad++ is sitting idle in the background? I can stop the continuous flushing either by exiting and restarting Notepad++, by switching to a tab/file that has not been modified since I started Notepad++.exe, or by saving the current tab to disk via Ctrl+S.

If a file was already using the npp/backup copy (red tab) when I started Notepad++.exe then Notepad++ does not flush the file(s) to disk every 7 seconds. The continuous every-7-seconds flushing starts as soon as I type a single letter into a file. It does does not stop when I use Ctrl+Z undo to restore the file back to the state it was in when I started Notepad++.exe.

@Eric-Pendergrass likely has his Notepad++\backup folder included the things monitored by OneDrive as he wants his off-machine backup to stay up to date. Normally we’d give a person an all-thumbs-up for doing that.

@Eric-Pendergrass - you can work around the issue by switching to another file/tab in Notepad++ that has not had any changes made to it since you started Notepad++.exe. If the current active tab has had any changes made to it since you started Notepad++.exe then Notepad++ writes it to disk every 7 seconds meaning your OneDrive updates the Internet based copy of the file even though you are not making any changes.

Alan Kilborn

@mkupper said:

What I am seeing is that if a file/tab has been dirtied since I started Notepad++.exe that Notepad++ starts writing that file to the backup folder every 7 seconds when it is the active tab

I can confirm this behavior with 8.7.6 and 8.7.7; I didn’t try any other versions
I would add to @mkupper’s description: “…and there is no need to write the file because the data has not changed”.
@mkupper Are you going to put in an “issue” on github about this behavior?

Lycan Thrope

@Alan-Kilborn ,
I’m just not sure if it really is an issue. It seems, according to @mkupper solutions, it would seem that on selection and change of a tab, the session 7 second back up kicks in…happening every 7 seconds. Once you change tabs, or save the document, I’m guessing, it flushes the signal to back up that particular document, so…If I use logic on this scenario, it appears it’s working as designed, unless you change the value of back up frequency, or you turn if off, at which point, you now don’t have snapshot backup. Double-edged sword.

Alan Kilborn

@Lycan-Thrope

If the data hasn’t changed, there’s no reason to bother the file system. Period, end of story.

Lycan Thrope

@Alan-Kilborn ,
Perhaps. But maybe making the first change, and not saving it, causes it to continually back it up regardless, until an event happens that stops it from focusing on that document/tab, and turns its attention to other tabs/documents that aren’t changed yet. It’s just a thought, since I’m not sure how the developer implemented that situation. Could it be that it doesn’t check to see if there was a change, after the first one signaled a change occurred that started it?
Maybe before putting in a report of the bug, try shutting off the Session Snapshot and periodic backup or varying it’s frequency, and see if the behavior stops or changes, first. Then we’ve isolated it to just that particular routine/implementation.

mkupper

Thank you for the feedback @Alan-Kilborn and @Lycan-Thrope. Hopefully I was able to integrate that into the github ticket.

I have created an issue at https://github.com/notepad-plus-plus/notepad-plus-plus/issues/16186
https://community.notepad-plus-plus.org/user/

I recall some changes a while back to prevent spurious backups of the non-active tabs. I now suspect that those changes resulted in Notepad++ never clearing its internal “file dirty” flag when it saves a file to the backup system. This flag is not same as the user-visible file-modified flag that causes the tabs to turn red. The issue started with v8.7.1 though the release notes for that version don’t mention changes to the backup system.

PeterJones

@Lycan-Thrope,

Perhaps. But maybe making the first change, and not saving it, causes it to continually back it up regardless, until an event happens that stops it from focusing on that document/tab, and turns its attention to other tabs/documents that aren’t changed yet.

The point is, that’s not how it used to be, and that’s not how it should be.

Using the definitions

make snapshot = automated system writes its temporary copy to disk in the backups\ folder
to save = the user does File > Save or equivalent, to write a permanent copy to the user’s specified directory

The old, ~~intended~~ desired behavior:

user edits active file
7 seconds later, N++ makes snapshot of the file
user doesn’t edit the file for 70 seconds, so no new snapshots are made
user edits active file
7 seconds later, N++ makes snapshot #2 of the file

The new, bad user experience behavior:

user edits active file
7 seconds later, N++ makes snapshot of the file
user doesn’t edit the file for 70 seconds, but N++ snapshots the exact same contents 10 more times unnecessarily
user edits active file
7 seconds later, N++ makes snapshot #12 of the file

~~The old behavior is what happened for all the years of Notepad++ “session snapshot and periodic backup” existence, until v8.7.1 changed the behavior.~~
update: per Don’s comments in the linked issue, and the issue it linked back to, apparently, the always-write was always the intention, and implied that it’s always been the behavior, but I didn’t remember it doing that; either my memory is wrong, or …

Alan Kilborn

@PeterJones said :

the always-write was always the intention

Isn’t that the “lazy coder’s” way of doing it? And what’s the advantage?
Say it’s a huge file/buffer; isn’t that possibly going to take appreciable time to do a redundant save? (annoying the user as he can’t do other things while that is going on – I’d think).
I stand by my original stance that there’s no point in rewriting the same thing every so many seconds…
EDIT: Think of how many problems and discussion points simply wouldn’t exist if the “snapshot” capability itself never existed!

PeterJones

@Alan-Kilborn said in New API to fix eventual regression regarding SCN_MODIFIED for some plugins:

Think of how many problems and discussion points simply wouldn’t exist if the “snapshot” capability itself never existed!

Interestingly, the “app” version of MS Notepad recently informed me that it’s started to perpetually save – I don’t know whether that’s implemented like snapshot or the MS Sticky Notes (where it saves to a hidden file instead of your main file), or whether it’s done like N++'s AutoSave plugin.

… A quick web search tells me that MS has gone down the “session / snapshot” path, not saving over the original unless you hit SAVE, so MS is copying Don at this point. Next thing you know, they are going to implement Lexilla syntax highlighting instead of hooking it to an LSP. ;-)

Alan Kilborn

@PeterJones said:

“app” version of MS Notepad recently informed me that it’s started to perpetually save
MS has gone down the “session / snapshot” path, not saving over the original unless you hit SAVE

Yes. More reasons to NOT use it. :-)

Off-topic: FWIW, Mac’s TextEdit does this as well, and most Mac programs have always auto-saved everything. This drives me nuts because often I do things that I don’t want saved, just to “try something out”. Then I have to stop and figure out what I’ve ended up with when I’m done; something I want or something I don’t want. It’s happening more and more in the PC world now too, sadly (to me).

We’re in a world where less and less users care about the concept of a “file”. As one who creates data that then is likely to get moved elsewhere to a final archival spot, I definitely care about the notion of “file”.

Yep, I’m old school and want to be in charge of what gets saved, so I want the intentional save. And I definitely want it in Notepad++ (and luckily I can have that) – just mentioning N++ here to bring things back on-topic. :-)

mkupper

@all that are interested.

I took a look at the v8.7.7 code and it does appear to be “by design” in that there is no effort, at within the Notepad++ part of the code, made to maintain a dirty or modified flag. Notepad++ just loops and copies the current file to the backup.

There are still two puzzles but I’m too wiped out at the moment to dig into figuring them out.

If a file has a red tab meaning it has been modified and you exit/restart Notepad++ then Notepad++ loads the file from the backup, sets the tab to red, but then does not start saving the file to the backup file every seen seconds until you make more changes the file. This implies there is some sort of internal modified/dirty flag.
I started to look at the v8.7 code which is the last version that updated the backup once and then did not continue to update the backup file every seven seconds. So far, the relevant code seems identical to v8.7.7. I need to do a more thorough inspection if v8.7 vs v8.7.7 when the brain is more functional.

I was editing some large files today and having the internal modified flag always set definitely cause lags when I switch tabs. Notepad++ used to quietly update the backup within 7 second and to clear the internal modified flag. I’m happy though in that I now know why I have been experiencing far too many inexplicable lags when switching tabs.

Lycan Thrope

@mkupper said in New API to fix eventual regression regarding SCN_MODIFIED for some plugins:

If a file has a red tab meaning it has been modified and you exit/restart Notepad++ then Notepad++ loads the file from the backup, sets the tab to red, but then does not start saving the file to the backup file every seen seconds until you make more changes the file. This implies there is some sort of internal modified/dirty flag.

It could be, that the tab has it’s own notification flag that gets set, separate from the Session Snapshot and backup routine(s). There’s nothing saying that the one is directly connected/dependent on the other.

User changes document, message sent of change, that triggers a tab notification and also triggers the Snapshot/backup routines, that then loop on their own. When the document is reloaded from the last snapshot, it’s not changed, as it was saved in the last snapshot form from the last session, the session sets the tab flag as it was and on we go. So there is no need to start recording changes again… unless and until another change occurs again and initiates the process all over again.

I don’t agree with @Alan-Kilborn’s assessment, that it was lazy programming, more like, there’s so many moving parts, that trying to interlace them all into one homogenous blob of code would be daunting for anyone to even fathom, let alone produce. So for that reason, I can see the design choice, but now that someone has focused on it, as I read in @donho’s notes on it, says, if someone has a better idea and implementation…let’s hear… meaning it begs for someone to imagine/implement a better system. :-)

Alan Kilborn

@Lycan-Thrope said :

there’s so many moving parts, that trying to interlace them all into one homogenous blob of code would be daunting for anyone to even fathom, let alone produce

If this is the thinking, the project is in trouble.

donho

@PeterJones said in New API to fix eventual regression regarding SCN_MODIFIED for some plugins:

update: per Don’s comments in the linked issue, and the issue it linked back to, apparently, the always-write was always the intention, and implied that it’s always been the behavior, but I didn’t remember it doing that; either my memory is wrong, or …

Sorry I’ve provided the wrong information. Here’s the correct one:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/16186#issuecomment-2678965165

@mkupper said in New API to fix eventual regression regarding SCN_MODIFIED for some plugins:

A couple of weeks ago I noticed that Npp seemed to be writing to disk every 7 seconds despite Notepad++ being idle/unused at the time.

It’s a regression, and it should be fixed in the PR:
https://github.com/notepad-plus-plus/notepad-plus-plus/pull/16225

The fix will go into the v8.7.8.

ThosRTanner

Just a quick question - when will the plugintemplate repo be updated to include the new message?

Thanks