As @LarsGit223 confirms, there will be no save if the file is unmodified, making a change and then undoing it leaves the file unmodified, but two modifications that just happen to cancel each other out are still two modifications, so the file is not unmodified and the save dialog occurs.

We consider a file unmodified if it hasn't had modifications since the last saved state: you can see this as matching the last "checkpoint" in the undo history. As @elextr said, modifications that just so happen to result in the same state are not considered the same, but if you undo your changes until the last checkpoint is reached it'll be considered unmodified (you can tell in several places in Geany's UI).

Yes, we *could* check the differences between the current state and the last known saved state, and if it's the same not bother. However: * it has to be done and is harder than what we currently have * losing undo history might be a problem, so current situation mitigates this * I don't think it's worth the hassle of implementing it (esp. for a behavior that might not please everyone) * AFAIK all other apps I know behave the same, which at least means we're not the odd kid in the playground

--- BTW, one could probably write a plugin that somewhat does that by adding a save point (`SCI_SETSAVEPOINT`) when the buffer matches the last one again. I'm not 100% sure it'd be enough, but it someone really wants this it might be worth trying it out through a plugin.

This seems like a perfectly reasonable feature request and would be super trivial to implement:

```c if (doc->file_name == NULL && sci_get_length(doc->editor->sci) == 0) { // don't prompt to save, just close } ``` I bump into this all the time, although it's not a major annoyance, I've got into the habit of working around by undoing the few changes until the "untitled" tab goes back to black and then I can close without the nagging.

Re-opening issue since no reason for closing was given and @b4n seems to be talking about a "saved"/disk document as opposed to an "untitled" document.

The "existing capability" label is the reason for closing

It's not an existing capability, although "workaround available" would be fitting.

please don't hijack issues for different purposes (don't ask to close empty files).

I'm not, it's what the OP said above:

...

if a new file is opened, stuff gets dropped into it and then ctrl-X'd out of it, closing should not prompt for save.

Anyhow closing and saving empty files is a perfectly reasonable thing to do.

I'd wager it's far less common than using a temp/untitled file as a scratch buffer (at least for me it's _way_ more common).

The newly proposed change would remove that possibility.

For the unusual case where someone just wants to create a blank file in a text editor they have no intention of editing, they can just use the Save As button/menu/keybinding, easy peasy.

@ntrel ideally the tab wouldn't be red if there were nothing to save. If you want to test it out, install VSCode. Instead of red tab label it turns the "close tab" X icon into a circle, but it's the same idea, it switches the state of tab depending on whether there's anything to save to disk.

No scores, just whether it's helpful to nag about an unnamed empty document or not.

It's helpful because other editors also do it and also have bug reports about it?

It's not that much ado, basically just adding a special case on a special case.