Community
Participate
Working Groups
Build ID: Version 3.2.0 M20060629-10-5 Steps To Reproduce: 1. enable "Refresh automatically" 2. open a file in an editor 3. edit this file externally and save it -> editor shows the changes automatically 4. edit this file a second time and save it -> editor does not show the changes 5. go with mouse onto Eclipse editon -> Eclipse asks "file has changed ..." Then behaviour continues with point 3. More information: every other time, Eclipse asks for confirmation - that's a bug. BTW. One should be able to specify "auto-reverse" on a file basis!
I cannot reproduce step 4 i.e. that works for me. NOTE: the auto-refresh mechanism is not live i.e. it runs from time to time and hence you might have hit before it ran. >BTW. One should be able to specify "auto-reverse" on a file basis! Do you really need this on a per file basis? Wouldn't it be good enough never to ask if "Refresh automatically" is checked? Of course there would always be a dialog for dirty files.
> I cannot reproduce step 4 i.e. that works for me. NOTE: the auto-refresh > mechanism is not live i.e. it runs from time to time and hence you might have > hit before it ran. You are right! I'm just too fast. But then Eclipse should simply refresh a file (if auto-refresh is on) in case if there is a difference between its version in the editor and on disc. > Wouldn't it be good enough never to ask if "Refresh automatically" is > checked? Of course there would always be a dialog for dirty files. Sorry, I don't understand this comment. I'd like to see "Refresh automatically" on a file-by-file basis because normally I'd like to know if "something" changes my files. Only for some exceptional files, e.g. logfiles, I know in advance that it is allright.
>Sorry, I don't understand this comment. Exactly what you wrote in the first paragraph of comment 2 ;-)
> Wouldn't it be good enough never to ask if "Refresh automatically" is > checked? That would be almost all the way. But see my last paragraph of comment #2. > Of course there would always be a dialog for dirty files. But if "Refresh automatically" is globally active (i.e., for all files) what then is a "dirty file" (in comparison to a "normal file" that has been changed externally)?
(In reply to comment #4) > > Of course there would always be a dialog for dirty files. > > But if "Refresh automatically" is globally active (i.e., for all files) what > then is a "dirty file" (in comparison to a "normal file" that has been changed > externally)? please ignore my last comment. Sorry.
If you want both then you need two bug reports ;-)
(In reply to comment #6) > If you want both then you need two bug reports ;-) No, I don't want to ask for too much. > Wouldn't it be good enough never to ask if "Refresh automatically" is > checked? Of course there would always be a dialog for dirty files. That would be perfect. Ulrich
OK then. Since this mainly applies to the textual editors I move this to Platform Text.
On a closer look we cannot reuse the existing preference because - it is on a different layer and - a user might want to disable auto-referesh of the workspace but have the content of editors updated automatically
*** Bug 174146 has been marked as a duplicate of this bug. ***
*** Bug 174252 has been marked as a duplicate of this bug. ***
Another problem is that the refresh might have not yet been processed when switching back and hence you might get unexpectedly asked when saving the file. What if the file in Eclipse is dirty?
I don't think this necessarily needs to apply to just text editors, but certainly it might make sense to implement it for these to start. I think that the behaviour if the editor is dirty is to do the same in Eclipse at the moment -- that is, don't prompt for changes (but maybe report that the file is out of sync when saving). PS for reference, NetBeans 5.5 and IntelliJ 6.0 automatically reload changes in editors made outside the IDE when the editor is activated. I can check what happens in the dirty situation. It was pleasantly surprising to do some changes and see them automatically updated -- I can understand how a user coming from one of those to Eclipse would be frustrated. PPS if a new preference is enabled, then having a 'Do this from now on' checkbox on the dialog would also be a good place to enable the user to make the change. PPPS can I help out with providing a patch for this?
>I don't think this necessarily needs to apply to just text editors, but >certainly it might make sense to implement it for these to start. Agree. Hence Platform UI (or IDE) should offer that preference and once it is there editors can start to adopt it - textual editors being the first ones. ==> moving to Platform UI to add such a preference. I'm moving this back to UI to provide such a preference on the 'General' > 'Editors' preference page. >I think that the behaviour if the editor is dirty is to do the same in Eclipse >at the moment -- that is, don't prompt for changes That's not how text editors currently behave. They always prompt if you activate an editor that operates on a out-of-sync file. And I think this should even be done if the preference is enabled because when we do it on save the user might have lost the context already. >I can check what happens in the dirty situation. Yes please. >It was pleasantly surprising to do some changes >and see them automatically updated Eclipse editors do that too if 1. the file in eclipse is not dirty 2. the save outside eclipse is recognized and sent as resouce delta by Platform Core before the user (too quickly ;-) switches back >PPS if a new preference is enabled, then having a 'Do this from now on' >checkbox on the dialog would also be a good place to enable the user to make >the change. +1 >PPPS can I help out with providing a patch for this? I think if Platform UI agrees to provide the preference then this would be a nice spot for providing the patch. I can then add adopt in in Platform Text.
Boris, I added you since you've been in the code most recently but I've assigned it to Duong since he's the component owner...
We are interested in looking at a patch if anyone would like to contribute one.
I'd like to support reopening/assigning this bug. For my usage -- examining the output of an executable -- it is unworkable to the extent that I am having to write code that sends file to console to avoid clicking through these dialogs. I might suggest finer-grain control, that is you could set a file type or working set only to be auto-refresed.
if you submit a patch we would be happy to review it
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
