> I think, with bugs in general, frequency of occurance is hard to guess. For 
> example, in the majority of my past projects, I was the only one who actually 
> reported issues with software. Most other people either ignored the problem, 
> or switch to a different software. Especially in the case of a free text 
> editor, by far most users who experience this kind of problem more than once, 
> will simple turn to a different program.

Yes you're correct, so, since the local psychic is on summer holidays, all we 
can use is reporting frequency.  As for the assumption it may be scaring away 
users, this is one of the rare situations where I agree with RMS (program name 
removed):

```
We would like more people to use <our program>, but we should never think
that we _need_ more users.  When developers of a free software package
think they _need_ more users, it is a lever that can be used
to push them into bad decisions.

When some people use <our program>, they are getting benefit from our work.
We are glad it benefits them, we intended it to benefit users, and we
hope to make it benefit them more, but we don't _need_ them to be
pleased with our work.  We're the ones who did them a favor -- not
vice versa.

Likewise, when some people don't use <our program>, that's their loss, not our
loss.
```

So we tend to do stuff for us, then those who report it, and not those who 
don't.  Now you have reported it, we are looking for a solution, but not at the 
cost of reducing service to the flakey network brigade who have already 
contributed reports in the past.

Sorry to go all philosophical on your Issue, now back to normal service :)

> I don't know to what extent the network is flakey, but in many companies, it 
> is strongly discouraged to have any file on your local drive (becaue it 
> doesn't get up).

"backed up" I assume you mean, yes, thats why simply refusing to save "remote" 
files is a "bad thing" :tm:.  "Remote" files can be connected via local gigabit 
connections that are more reliable than the disk drive, to connections to a 
remote server via coffee shop wi-fi or overloaded zero strength cell 
connections using sshfs, we don't know.

> The problem is not so much editing over the network, but editing files which 
> are accessible to many people, and of course this can lead to race 
> conditions, which would also exist if I would copy the file to my local disk, 
> and write it back when I'm done.

Well, as @codebrainz pointed out, failure to save can still be triggered on 
local files too, and on Linux, for example if you or one of your scripts 
changed the file permissions, or the disk filled up.

> The plugin needs to make sure that the clock counting until the next attempt 
> of saving the file, is reset to zero when the user clicks the OK button of 
> the pop-up message. He has then time to save the file under a different name 
> (if he sees no possibility to remove the lock).

It would have to disable the "save on focus out" feature, because, having had 
the popup, a `focus_out` event is already queued to re-trigger the sequence, 
thats where the loop is.  The question is then when to re-enable it since the 
user doing save-as does not involve or inform the plugin its done.  

Also I'm not sure its possible to reset or cancel the timer, you have to 
actually get a timeout and return `false`, @b4n would know.  But the timer 
triggered saves should not be a problem (well it might be if the user set a 
really small timeout, but that will cause a problem in their normal usage, so 
its not likely), you might get one extra timer triggered save and failure 
dialog, but once you start the save-as process it can't be interrupted because 
the dialogs are modal (thats *why* the dialogs are modal :).

But someone has to come up with a good suggestion on how to re-enable the 
plugin, or how to otherwise break the focus-out loop long enough to save.  
Because the alternative of disabling the plugin and notifying the user via a 
popup dialog is going to be an issue for the flakey network brigade who will 
get it regularly.



---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/815#issuecomment-165629484

Reply via email to