Here's a patch. It was pretty easy to make: konsolebox@e329b28

I can create a PR if it's really wanted.

... separating rename and save is a better idea still.

In the context of stand-alone renaming yes, but if it's about a document not, because like I said every caller would make sure that all necessary listeners to "document-save" would get notified about the change. I'm not sure if it makes sense to have the GeanyDocument stay as is while the name of the file in the filesystem gets changed. I don't say any use case for it. Not to mention document_rename_file() already calls document_stop_file_monitoring() and it expects document_save_file_as() to be called after. We wouldn't want plugins (or anything that calls document_rename_file()) to always do both sequences separately.

... Ok, maybe since nothing is really changed in GeanyDocument when a file is renamed, notifying listeners to "document-save" may not be necessary (until the save operation actually starts), but both operations are still better put together in a single API function due to the fact that document_rename_file() can't be used alone in one operating session.

Here's a gist for the function: https://gist.github.com/konsolebox/b95bd34e518ac1d1aa60a6348bd498b9

There are surprising things about doc->priv->file_disk_status but I haven't looked into it thoroughly yet. Basically the idea is that document_save_file_as() does not revert doc->priv->file_disk_status to its original state if the save fails. And so does document_rename_file(). Simply because it can't, because it's used separately from document_save_file_as().

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.