-
-
Notifications
You must be signed in to change notification settings - Fork 552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Close without saving modified files #81
Comments
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:
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": |
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 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, 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:
DownloadAll 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:
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 |
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 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:
BTW: Can you change the process name to something more meaningful? Bonus thoughts:
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 @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
No clue how to do it or if it is possible but I agree it is very generic and not helpful.
On Windows it is very similar though it is called
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.
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
is "none". Random source: https://stackoverflow.com/questions/15766036/sigkill-signal-handling |
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 |
Definitely not a good idea. :)
Possible to do with some care. |
"Definitely not a good idea" - dito :) Thanks for your work |
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:
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. |
I've not got this to work yet, although i notice that you say there's a
setting, so I'll go find that.
that said, when are we saving the modified files? if we're saving as we go
along, every few seconds after an edit, then the edits are safe and even
complete power loss won't harm us.
unless one of these events occurs during the actual saving process, but we
can still mitigate against even that with minimal loss.
…On Fri, 13 Jan 2023, 13:37 dail8859, ***@***.***> wrote:
@dzek69 <https://github.com/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
<https://doc.qt.io/qt-6/session.html> that may be the solution to
handling these signals in the recommended Qt way.
—
Reply to this email directly, view it on GitHub
<#81 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFHFBW4SWIWST2ND6ZPYULWSFLCZANCNFSM5S7GDFQQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
@Rcomian It is in the Preference dialog. Shouldn't be too hard to find since there isn't much there yet.
On application shutdown |
ah yes, that's gonna leave us vulnerable, unless as i say, we save as we go along. |
dail8859 isn't too eager about this either, as "save as we go along" would basically mean "on every key stroke" "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. :)" |
It is meant to save temporary changes between application restarts. If the text you are modifying is important, save it to disk. |
nah there's definitely a balance to be struck. we're not after nuclear
grade data retention, just a reasonable expectation that it'll generally be
there.
for example, register for an "edit" event, when it fires, set a timer for 2
seconds. when that fires, first register for the edit event again, then
save the file (if a previous save of this file isn't still in progress).
that way, if you press a key, within a few seconds it'll be safe in the
temp area. if you're constantly typing, it'll be saved as you go. no need
for every individual change to be saved.
we can also balance it other ways, like save 2 seconds after the first
edit, then every 10 seconds until the document is left idle again. and the
timings are only suggestions.
or we can wait for a 2 second idle period after typing before saving. stuff
like that.
…On Fri, 13 Jan 2023, 14:04 mikelupe, ***@***.***> wrote:
dail8859 isn't too eager about this either, as "save as we go along" would
basically mean "on every key stroke"
"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. :)"
—
Reply to this email directly, view it on GitHub
<#81 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFHFBVNLRAL677J3WBR3ADWSFOH5ANCNFSM5S7GDFQQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I'd go with saving session 3 secs after last key press. It's a balance between performance degradation caused by instant saves and reliability (if I lost something I just typed it's not that bad, at least I remember it and I should be able to notice if app/power/whatever crashes) |
Trying to handle "sigkill"s AFAIK means "having a wrapper process" that monitors those kills, but for something like that a lot of logic would have to be moved there and still on shutdown OS will kill anyway. It's a risky path that probably leads to nowhere anyway |
I'm not saying I'm against this, just rather the "saving session state" versus the "back up my files in case of a system/application failure" are slightly different features. Yes there is quite a bit of overlap for sure (maybe even more than I realize?)
Agreed and as @Rcomian stated If someone wanted to open an issue or discussion around more of the backup functionality it is definitely worth discussing. |
I don't expect a backup solution too. In my 3-4 years of using N++ it lost my session once, but my files could still be found inside the If that would be a session reset every 2 months then i'd prefer not to have this feature at all, "no safety measures" sounds better than "safety measures that sometimes fail", because I'd just know I should save all the time. |
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
The text was updated successfully, but these errors were encountered: