NotepadNext
NotepadNext copied to clipboard
[Feature Request] Close without saving modified files
The default behaviour in Notepad++ has always been to retain any modified buffers when closed without prompting the user to save. This would be a useful feature to have in order to use NotepadNext as a scratchpad of sorts.
Thanks, digg33
Thanks for opening this issue.
I know this is a very useful feature in Notepad++ and alot of people like it. I think for the general audience that this fills a huge need to keep temporary notes, have a scratchpad, etc (personally I hate this feature, but that's beside the point 😄). There's a bit of work that will need done beforehand to make this feasible to implement, such as better preference handling and session saving/loading. Once those are working properly then keeping unsaved files would be much easier to implement.
This feature is basically one of the main reasons for me to use Notepad++ (through Wine). I thought this was quite "simply" solved - each unsaved tab exists as a temporary file. Or isn't it that "simple"?
There is some extra 'meta' data that needs associated with the unsaved files. Along with storing the actual text, the Notepad++ session stores things such as:
- firstVisibleLine
- xOffset
- scrollWidth
- startPos
- endPos
- selMode
- offset
- wrapCount
- lang
- encoding
- userReadOnly
- filename
- backupFilePath
- originalFileLastModifTimestamp
- originalFileLastModifTimestampHigh
I don't think all of these would be required immediately, but having session saving/loading capabilities would be needed to make keeping unsaved files much easier. All possible in theory, just some additional groundwork that would help making this functionality possible.
Yes, I see - thanks for the wrap-up :)
Absolutely this feature. As has been mentioned, it's the reason for using/wanting a notepad++ like editor.
+2 from me and my gf, this is the main reason I even use notepad++ and the main reason I will use this app when I will switch to linux again
even the simplest implementation would be perfect
And something for this post not being just another "me too": I see the project got to trending list again, maybe it'd be a good idea to open some donations? (not to mention feature request-based donations if you like others to set up your priorities, but it's 100% up to you!)
There is some extra 'meta' data that needs associated with the unsaved files. Along with storing the actual text, the Notepad++ session stores things such as:
- firstVisibleLine
- xOffset
- scrollWidth
- startPos
- endPos
- selMode
- offset
- wrapCount
- lang
- encoding
- userReadOnly
- filename
- backupFilePath
- originalFileLastModifTimestamp
- originalFileLastModifTimestampHigh
I don't think all of these would be required immediately, but having session saving/loading capabilities would be needed to make keeping unsaved files much easier. All possible in theory, just some additional groundwork that would help making this functionality possible.
Would you consider using SQLite for this session stores functionality?
Would you consider using SQLite for this session stores functionality?
SQLite would be too much for the needs. I don't think the root of the problem due to how much data is stored or searching through it.
The built-in QSettings
functionality that uses INI files would most likely be sufficient and would be the easiest way to implement it. The bulk of the work would just be implementing the functionality within the application to appropriately store and reload the session state.
Personally, I don't use this feature in Notepad++ so I'm not overly familiar with some of the possible corner cases that would need handled. If I have some free time in the near future, maybe I'll take a quick attempt at the functionality to see what kind of questions/issues I run into.
All, I've started testing out some changes in #264 to work towards this feature request. This is a first attempt at saving/loading a user's session (does not currently save unsaved files yet) between application restarts. It does reopen previously opened/saved files.
If you are interested in testing these changes (as I am sure there are bugs), use the links at the bottom to download a test build for your system. (If someone wants a flatpak beta release let me know). Please post on #264 if you find any issues or have questions. I intentionally did not try to match all of Notepad++'s behavior identically. I'd rather start simple, and then address concrete use-cases as they arise.
Please note:
- This feature is not enabled by default. This needs enabled through the preferences dialog.
- This feature does not currently save temporary files (that will come later). This base functionality is needed before temporary files can be properly saved/loaded.
Download
All of these are zip files. You will have to unzip them first.
After quick testing I couldn't find any bug, I just found something that's probably unfinished:
- it remembers scroll position, but it doesn't remember cursor position
- it doesn't remember which tab was left in front (always focuses the last one)
Good work!
Edit: tested on Windows
New download:
Cursor position is restored, and previously active tab is focused.
Again these are all zip files so you'll have to unzip them first.
Windows and Linux version seems to work flawlessly (I spent just few minutes on them). Thanks!
After you will add a way to remember files without saving them I'd gladly donate to this project and start using it on a daily basis 👍🏻
Any updates on this? Where can I try this feature. In the settings there is no option to enable it?
The PR builds linked has some basic functionality. It is not in the main release yet. Progress is slow as I've been quite busy lately. The basic 'loading a temp' file functionality is partially working, but there are some non-standard things that just aren't built into Scintilla (the main text editing part of the app) and trying to dig through the Notepad++ source code is quite painful.
After rewriting the logic probably 4 times, finding bugs I thought I introduced, and several iterations of code cleanup, I think this is pretty close to "functional".
There are bugs. This should be considered very experimental and could possibly cause you to lose data if you enable the options.
Please test this out and when you run into issues, the better you can describe the problem and the steps to reproduce it, the quicker I can fix it.
Any and all feedback is welcome.
Latest Downloads:
Thanks to @mikelupe for pointing out a couple issues that should be fixed now:
@dail8859 I'm a bit late to the party as I was in the middle of setting up my fresh Linux installation, but just wanted to give feedback anyway that this seems stable for me (the version you posted 5 days ago). I'm using Notepad Next as main notepad app for few days and it should stay like that, so if you need to beta test something - please mention me with @dzek69 and I'll be happy to test.
Yup, this seems to be working great, that's the only function that was keeping me from using Notepad Next as my daily driver, thanks a lot!
Any ETA when this might hit Flatpak build (AppImages don't play nice with gnome dock favorite and for me, this is crucial for my notepad to be as quickly accessible as possible)?
I wanted to report I had a data loss yestarday, I had just one file open with unsaved data, I restarted my OS and next time I started NN there was nothing. I did not try to reproduce yet, now I'm a bit too busy.
I wanted to test first before leaving a comment but if somebody (looking at you @ekasprzak) want to rely on this - don't do it yet :)
@dzek69 That's unfortunate to hear but I guess I'm not super surprised since this is a brand new feature. Any details would be appreciated if you do happen to track it down some more.
Given there still seems to be some bugs to work out, I'll push a change soon that will at least warn the user of possible data loss when enabling this feature. Data loss is by far the worst possible kind of bug! This way I can still proceed with a new release for users that are wanting to give it a try.
@dail8859: hey, I discovered how to reproduce it. Well. I even wrote here about that and I was waiting for response, but it looks like I did not press the submit button or GitHub lost it between the bits.
Anyway, if you kill the app with SIGKILL signal it will always loose all the state. That's the tl;dr info.
Example how do I reproduce it:
- Open NN
- In the terminal do:
top -b -n 1 | grep wrap
and remember the pid (first number) - In the terminal do:
kill -9 INPUT_PID_HERE
- You should be able to replace step 2 & 3 with
killall -9 AppRun.wrapped
, but it seems that process name of NN is kind of generic and that could kill some other apps as well if you happen to run one with the same process name.
BTW: Can you change the process name to something more meaningful?
Bonus thoughts:
- Notepad++ keeps the never-saved-yet (all the
New 1
New 2
etc) files in abackup
directory in AppData. - I think this is nice idea - it's bulletproof, because it's always on disk, you can nuke the app and it will persist.
- Bonus points for easy recover if your whole OS is dead
- More bonus points for naming pattern - like
new 6@2022-12-19_153239
- file creation date is in the name, and last modified attribute can be read from filesystem attributes - this once helped me a lot when I thought I lost something important - I have no idea how they save the modified state of existing file without actually overriding them - there must be some session data stored as well, that keeps track of that + the order of tabs (you can't figure that out from just filenames)
But I hope there is no need to recreate things the same way and you can solve killing app issue (I guess most Linux OSes will always kill the app when shutting down, so this is something that will happen quite often to users) before releasing the app with this feature.
@dzek69 , @dail8859 I was about to report a similar thing, so I can confirm this.
I realized this happens when shutting down the machine, which basically means notepad-next is recieving a SIGKILL signal.
@dzek69 @mikelupe Thanks for the info!
I'll have to do some research to see what kind of signals are generated in the application itself as the QCoreApplication::aboutToQuit()
doesn't seem to trigger under non-graceful circumstances as you've found.
Can you change the process name to something more meaningful?
No clue how to do it or if it is possible but I agree it is very generic and not helpful.
Notepad++ keeps the never-saved-yet (all the New 1 New 2 etc) files in a backup directory in AppData.
On Windows it is very similar though it is called session
as I personally think this is different than a 'backup' type of feature (but that's kind of beside the point). According to https://github.com/dail8859/NotepadNext/pull/264#issuecomment-1366923013 on Linux it is saved to ~/.local/share/NotepadNext/NotepadNext/session/
More bonus points for naming pattern - like new 6@2022-12-19_153239 - file creation date is in the name, and last modified attribute can be read from filesystem attributes - this once helped me a lot when I thought I lost something important.
Then UUID was a quick and guaranteed way to create a unique file name. In theory using the name + file create date is mostly safe but still possible to have clashes and loss of data.
before releasing the app with this feature.
v0.6 is now available with this feature. If I can get some of the bugs fixed soon I'm fine pushing out a minor release especially if it is to prevent possible data loss.
AFAIK the answer to
what kind of signals are generated in the application itself
is "none". Random source: https://stackoverflow.com/questions/15766036/sigkill-signal-handling
According to https://github.com/dail8859/NotepadNext/pull/264#issuecomment-1366923013 on Linux it is saved to ~/.local/share/NotepadNext/NotepadNext/session/
Right. It's there. And it's updated only on proper shutdown, so if I close the app with some data (like "aaa") and reopen it, change the contents (to "bbb"), kill it and open it again - i will have something - it will just be outdated ("aaa").
I guess you can just save it periodically :)
Last comment in this issue. I didn't want to copy the whole convo to the new one. Sorry for the chaos :)
I was thinking about the periodic saving, but this isn't really realiable I guess :) The only reliable way imho would be to save on every key-stroke, but I'm not really sure this is acceptable performance-wise. Or is it?
edit: ev. sigkill handling IS possible in some way? Unfortunately I'm not a developer, but I almost can't imagine this not being an option
The only reliable way imho would be to save on every key-stroke, but I'm not really sure this is acceptable performance-wise.
Definitely not a good idea. :)
sigkill handling IS possible in some way?
Possible to do with some care.
"Definitely not a good idea" - dito :)
Thanks for your work
@dzek69
is "none". Random source: https://stackoverflow.com/questions/15766036/sigkill-signal-handling
Agreed. There are some signals that are a nuclear option and data loss and/or non-standard behavior are expected.
https://man7.org/linux/man-pages/man7/signal.7.html states:
The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
That being said a graceful system shutdown should send other signals that can be handled. Qt also has Session Management that may be the solution to handling these signals in the recommended Qt way.