When open files are deleted from the filesystem, Geanys behaviour is not very intuitive and somehow contraproductive. It offers to save the file again and does not give me the possibility to close the document.
I suggest to change the dialogue to "File was not found on the drive. Close the file and discard content? Yes (Close the tab, do NOT suggest to save it again.) Yes (Do noting, keep the tab open),
Main use case: Editing files on a remote server by FTP with Filezilla: -Several files are stored in a temp folder. -I can edit them with any editor -Filezilla tracks changes and lets me update the files after changes -When I am done, I close Filezilla and the Temp files are deleted by Filezilla. In that case I want to get rid of the open files quickly and do not want to store them again. Why should I?
Other use case: editing files that are stored in a cloud and have been deleted in the meantime.
Reference for a better solution: -Notepad++
The point of offering to save again is to protect users from accidentally losing something in common use-cases. There are many things that can cause a file to be accidentally removed, in particular version control checkout changes, and renames. These are the common use-cases that Geany was designed for.
So the current behaviour won't be changed.
But that said a "Close and don't save" option could be added to the infobar. Pull requests are welcome.
BTW Referencing the behaviour of another tool that most Geany devs don't have is not useful, describe the desired behaviour.
It offers to save the file again and does not give me the possibility to close the document within that dialogue.
It's not a blocking dialog, it's just a passive infobar, so you don't have to do anything with it. In the case the file was deleted, there are no less than 4 ways to close the file: the tab close button, the close button in the toolbar, the close menu item in the file menu, as well as <kbd>Ctrl</kbd>+<kbd>w</kbd>. If the extra step of confirming you want to lose your open document is the problem, it can be quickly dismissed using the keyboard with <kbd>Alt</kbd>+<kbd>d</kbd>.
But that said a "Close and don't save" option could be added to the infobar. Pull requests are welcome.
Seems reasonable, if maybe a little dangerous. I can imagine someone accidentally clicking the wrong button in the infobar and then having a really bad day, but I'm not strongly against it if people would find it useful for their workflows.
Seems reasonable, if maybe a little dangerous. I can imagine someone accidentally clicking the wrong button in the infobar and then having a really bad day.
Agree, thats always the risk, but its the same risk as incorrectly clicking "don't save" on the normal close dialog.
elextr: BTW Referencing the behaviour of another tool that most Geany devs don't have is not useful, describe the desired behaviour.
Hi, I tried to describe the desired behaviour. If anything else would be needed, please let me know.
codebrainz: Seems reasonable, if maybe a little dangerous. I can imagine someone accidentally clicking the wrong button in the infobar and then having a really bad day,
Yeah well, I had this really bad day, two days ago. I accidentally overwrote several files on my webserver because (?) the files were still open on two machines. No, I am not blaming anyone but would like to reduce that risk. Offering to save files that have just been deleted even if there are no unsaved changes in geany seems a bit like questioning something that the user has just done, like do you really want to leave my website?
I tried to describe the desired behaviour. If anything else would be needed, please let me know.
Ok, but since you referred to another application as the "reference for a better solution" its possible that it had another behaviour.
Offering to save files that have just been deleted even if there are no unsaved changes in geany seems a bit like questioning something that the user has just done
Note that Geany does not know that the file has been deleted, and the infobar does not say that, just that it was not found. An example of a situation which will bring up that infobar is if your remote webserver filesystem loses connection. Then you probably would want to save the file, albeit in a different place, until you sorted the connection out so the save option opens the save dialog for that reason.
Agree, thats always the risk, but its the same risk as incorrectly clicking "don't save" on the normal close popup.
The difference is the infobar provides the notification first, and then the _modal_ dialog confirms the action after. I could imagine a case where someone is going really quick and presses whichever keybinding/mnemonic activates the "delete this buffer" button in the infobar accidentally. Or perhaps they're in another window in front of Geany, managing the files, and temporarily moving/deleting the file knowing it's safely open in Geany, and then they go to click the Geany window to activate it and accidentally click the "delete this buffer" infobar button and lose the document. Just a couple examples, albeit far-fetched, off the top of my head.
I thought about this and had a closer look on the behaviour of geany.
You are right, it is the same or similar effort to close an unwanted file.
The real difference is, when doing this with several files, that are spread among other files that should be kept in the editor.
Geany does not help me to quickly access those files quickly. I have to think which ones are affected and open them manually.
For my use case (getting rid of the files quickly) and also for the other use case (I want to save the files, so nothing gets lost) it would be great to put the deleted files up front, one after the other and display the notification. Then the user could either close or save all of the files.
What do you think?
Geany does not help me to access those files quickly. I have to think which ones are affected and open them manually.
Agreed, but in fact Geany does not know about those files either, it only regularly tests the current file. This is to reduce the cost of regularly `stat`ing lots of files which can be an expensive operation, especially if the user has many files open, and/or if files are on remote servers. And some users have a LOT of files open, and as home file servers get cheaper more use "remote" servers.
There was an attempt to use the GIO file monitoring which may have been able to handle more files efficiently, but it proved to be unreliable, triggering multiple times and causing the infobar to come back repeatedly. This may not neccessarily be GIOs fault since the underlying OS `inotify` interface notes the possibility of missing or repeated events. This code is still in the Geany source but `#if`ed out, anybody is welcome to try to sort it out.
it would be great to put the deleted files up front,
Even if monitoring worked, its considered bad UI design to reorder a users tabs. Other methods of indication could be used to allow the user to find such files quickly.
Other methods of indication could be used to allow the user to find such files quickly.
like on the sidebar in the "documents" page having a section inside it for "deleted documents"??
github-comments@lists.geany.org