Save and Restore Change History Markers

Vince Aman

I rely on the Change History Markers during my programming sessions. Having to switch between multiple clients/programs with each having 20k to 50k lines of code… Change History is one of my favorite features! However, a Windows Forced Update/Reboot deletes all the Change History Markers. I would love the ability to save/restore the change history for a session or individual files. This would also help when traveling (while Hibernate works, a shutdown/restart does not). It appears this request was mentioned a few years ago, but have not found a plugin or mention of this recently… WinMerge does allow me to compare previous files/updates, but it’s not as helpful as the ability to scroll directly to the Change History Lines, etc…

mpheath

@Vince-Aman

Change History is great feature, though programming usually uses involves a File Versioning System which keeps good progress with diffs, … . Each time I commit, I clear the Undo and Change History and then go another round of code.

The 2nd week of the month is usually reboot time. Prepare for the worst so I wind down by closing numerous projects and usually manually reboot and start small so an unexpected forced reboot may hurt less. Starting back up with projects is like where was I with what exactly.

The problem with your idea is make sure to prepare. The idea may have some benefit so did some scripting. The code makes a snapshot before editing the code and then later, which is after a Notepad++ restart, restore from the snapshot and then patch in the changes which will return a new Change History.

I posted a fresh GIST with BufferRestoreChangeHistory.py . It uses a little bit of code from another older GIST BufferPatch.py so I had a head start on how to do it. There is a readme.md with the GISTs that explain some more details.

The BufferRestoreChangeHistory.py script requires PythonScript 2 or 3. I usually use PythonScript 3 so it was lucky that testing in PythonScript 2 worked without any code modification. The code is fresh so advise to test before becoming dependent on it in a big way.

Vince Aman

@mpheath, Thanks for the reply!

I typically bounce between 3 or 4 clients per week with each having dozens of program files of 5,000 lines or more.

As I get older… it gets harder to remember all the changes to the files, since the applications from client to client are completely different programs with hundreds of variables, etc… Once I’ve modified a few hundred lines, with Change History highlighting, I can quickly scroll down (hyper wheel mouse) to locate the latest changes, etc…

I’ve created a versioning tool, which I use when I compiling code, giving me the option to capture a snapshot of the previous state. I use WinMerge and/or my own custom function to compare historical code, but it’s not the same as the visual markers showing those most recent changes.

What boils my blood is when I’ve worked one of those long 15/20 hour days and I’m mid-way through big changes, then go to bed to pass out, coming back to all my markers being gone from a Windows Reboot. I’ve continued to update group and registry settings to get the behavior to stop. While I have been successful in the past, every time I update my hardware, I miss some of those settings or an Win “update” resets something. Windows almost always bites me at the worst time…

The most recent event happened after I answered “no” to the update reboot notification, only to have Windows reboot just a couple hours later! It’s just so demotivating… I can say I’ve lost days (if not weeks) of work due to Windows forced reboots. I’ve learned to save often, and especially before walking away from my PC!

Thomas Anderson

I totally understand—Change History Markers are incredibly useful, especially for large codebases. A save/restore feature would be a game-changer, particularly to survive Windows updates, reboots, or travel situations.

Until a built-in solution exists, one workaround is to export or snapshot your files frequently and use tools like WinMerge or Git to track changes—but I agree, it’s not as seamless as scrolling directly to the Change History lines.

Hopefully, the dev team can consider a persistent marker feature in a future update.

xomx

@Thomas-Anderson said in Save and Restore Change History Markers:

Hopefully, the dev team can consider a persistent marker feature in a future update.

Scintilla editor component author is working on saving and restoring undo history, now also taking into account the Change History feature:
https://groups.google.com/g/scintilla-interest/c/CB20mc50kt0/m/ZNtpwjGxAQAJ

I’d pick this sentence from the above linked post:

"Explicit saving of change history state may be tackled in the future."

The whole feature seems currently unfinished:
https://www.scintilla.org/ScintillaDoc.html#UndoSaveRestore

I didn’t have time to explore the new Scintilla UndoSaveRestore APIs yet, but maybe someone else?

mpheath

@Vince-Aman
Could move development into a Virtual Machine (VM). End of day/night take a VM Snapshot and start the VM next day/night using the last snapshot and continue using Notepad++. Notepad++ could in theory stay running in the VM for months. VMs I find are good for testing though always feel restrictive and isolated which confirms why VMs are good for testing. I have not tried setting up full development in a VM though I have heard of one person who did this long ago.

@xomx
And this old link: https://scintilla.org/ChangeHistory.html
that mentions possibly connecting with Git or WinMerge somehow. These are only ideas but one day who knows what may develop.

I had ideas before creating the BufferRestoreChangeHistory.py script that a Version Control System (VCS) could be used as the snapshot. Basically any committed revision of the file could be used as the snapshot. The problem is which VCS to target as there are many of them. I usually use Fossil or Git. So went the option of using a SQLite database for the snapshot with the current buffer as it is known how to save and restore.

Looked at WinMerge .sct scripts. See no hints of accessing it’s change history markers. They are just visual markers lacking a working functionality as far as I know.

I didn’t have time to explore the new Scintilla UndoSaveRestore APIs yet, but maybe someone else?

As one person asks to the other person, what are you going to do. The other person says, depends on what are you going to do. Perhaps the creator of the new APIs is waiting for someone to actually use them and see what happens. Don’t look at me, I am not going to ask what are you going to do. :)

Ivy_Pearson

I heavily rely on Change History Markers during programming across multiple large files (20k–50k lines). However, Windows forced updates/reboots erase all markers, disrupting workflow.

I’d love a feature to save and restore markers for a session or individual files. This would also help when traveling (hibernate works, but shutdown/restart doesn’t). While tools like WinMerge can compare previous files, they don’t let me scroll directly to the Change History lines, which is crucial for productivity.

PeterJones

@Ivy_Pearson ,

Did you have something new to say? Because it really just looks like you are repeating essentially what was said in the original post.

mpheath

This post is deleted!

Vince Aman

@mpheath ,

Thanks again for you reply! I plan to test your BufferRestore script after my next “break” in my current project(s). After looking closer at your post and web page, this looks to be a good option for me to use until NP++ has a built in tool…

I do own a rack of servers and plan to spin up a couple extra VMs once I release my own platform/environment for my apps (within the next couple months). The challenge with one of the (main) current platforms which I’m using is, while I pay annually to be a developer for them, their licensing does not allow me to run on more than 1 PC at a time, so it requires me to log out/in each time I switch between PCs or VMs. I can’t maintain the variable “state” if forced to log out.

There are many additional issues with Windows Rebooting… When the current test environments get “killed”, all the opened files are now locked and all the variables are flushed. So it requires unlocking the files, and recreating the previous workflow to recreate the variable “state”. Using a log file doesn’t work well in this environment, because it typically goes back beyond the last save… and could only be applied if the saved file was in the exact state as when the log file was started… not sure if that makes sense?