On 15 May 2010 17:34, Lex Trotman elextr@gmail.com wrote:
On 15 May 2010 14:40, Jon Senior jon@restlesslemon.co.uk wrote:
On Sat, 15 May 2010 14:10:06 +1000 Lex Trotman elextr@gmail.com wrote:
Since it doesn't know the status of the directory the file was in or even the whole filesystem, and finding out could cause long delays as things time out, it is reasonable to ask the user where it is safe to save the file.
I agree. It is more than reasonable, it is to be praised. Better to harass the user a little than to risk losing data.
When a file of the same name re-appears the application can't know if it is intended to be the same object, so it has to ask the user.
Even after a reload. Here's the sequence of events (and this doesn't require a network drive to simulate)
touch foo.bar geany foo.bar (assumes an existing session)
[Edit file in geany and save using ctrl-s]
mv foo.bar bar.foo
[Return to geany, you will be prompted that the file can no longer be found and offered a chance to save it. Choose cancel leaving the file open but marked as dirty]
mv bar.foo foo.bar
[Return to geany and choose Reload. You will be asked to confirm and then the file is reloaded and it is no longer marked as dirty. Make a change and save with ctrl-s. You will now be presented with a "Save file" dialog]
I misunderstood, I thought you had said reloading stopped it showing a save dialog. I agree its superfluous if you have reloaded, and as I said I think you should be able to tell Geany that its superfluous even if you didn't reload.
This is, I feel, broken logic. The file was marked as dirty but has been reloaded from disk. A file reloaded from disk should be no different from a file freshly loaded for the first time. This does not occur if the file is not moved temporarily. By choosing to reload, the user has already resynchronised the geany buffer with the file and thus re-established the link between the buffer and the file. This final prompt is (in my opinion) superfluous.
Were it not for the painfully long opening time of the save dialog when dealing with a large networked directory of files, it would be a minor inconvenience, but while waiting for the dialog to open, you have time on your hands to think about this stuff! :-)
Heh heh, can't have users thinking now can we...
I don't wish to be critical. This is, frankly, my only issue with geany (I'd love it if it could convert R to optimised C, but I don't think that fits into the description of a lightweight editor!)
Sounds more like the job description of a compiler :-) but Geany can run one of those for you if you can find one :-)
. I know that I'll not have the time to track this down in the source for a while, so I'm putting it out there. I'm happy to submit a proper bug report if requested.
I'll have a look at the logic and how easy it is to change if no one beats me to it in the next few days.
Cheers Lex
This seems to be because when a document disappears the real path is cleared but when it is reloaded the real path is not set again. I'm not sure about side effects so I am asking Enrico or Nick, in document_open_file_full can the setptr( doc->real_path be moved outside the if (! reload ) safely?
Cheers Lex
Jon _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel