Bug 293056 - Don't offer to save new empty files
Summary: Don't offer to save new empty files
Status: RESOLVED INTENTIONAL
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
: 316558 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-02-01 15:41 UTC by Dotan Cohen
Modified: 2013-03-12 20:01 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2012-02-01 15:41:11 UTC
If a file has never been saved, and its contents is empty, please do no ask to save the file before closing it. I will often open Kate as a quick buffer for any number of tasks (view web page source code, quick note, etc) and if there is no text to save, then just close without a prompt.

Thanks.
Comment 1 Dominik Haumann 2012-10-26 13:01:39 UTC
If there is no content in a file and it is not modified, it will be closed silently.
If the contents is modified, we always ask, that's standard behavior we don't plan to change it, sorry.
Comment 2 Dotan Cohen 2012-10-26 15:33:42 UTC
Thanks, no problem.
Comment 3 Dominik Haumann 2013-03-12 19:58:00 UTC
*** Bug 316558 has been marked as a duplicate of this bug. ***
Comment 4 Dominik Haumann 2013-03-12 20:01:44 UTC
This wish came up just twice in the last 12 years. I'm not convinced that this feature is really wanted.

In fact, it might even be confusing. Think of writing a long text and then removing it by accident. Closing Kate/KWrite will loose all the data, no matter how large the undo/redo history is. It may be a constructed use case, but still, if the file is modified, it just makes sense to ask the user by default what to do.

If at all, it would be ok to add an option "[ ] Do not ask again for empty unsafed buffers" in the dialog or maybe add an option. But given that this feature doesn't seem to be desperately wanted, I'd just stick with the current behavior for now.