Bugzilla – Full Text Bug Listing
| Summary: | [IDE] Remove "recent file" history for items which don't exist | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | DJ Houghton <dj.houghton> |
| Component: | IDE | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | helmut.haigermoser, mober.at+eclipse, remy.suen |
| Version: | 3.1 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
DJ Houghton
hmm... actually tried this in a few other apps, and they don't remove it right away, but when accessing the file some of them give an error and remove the item, others leave the item and force you to a file dialog to find the file each time. Under the workspace model that Eclipse uses for file management, I think it makes sense to clean up the Recent Files list once a file is deleted. A trickier and possibly more important issue to solve is the one Michael elaborated on - if the user deletes a file outside of Eclipse, how does the Most Recent Used files list get updated? Solving this would provides a catch-all for the original case, although it would be cool to see both solutions. As for what different apps do when accessing such missing files, there's one behaviour which I find really irrating -- that's when its hard for dead files to be removed from the MRU (ie. it gives an error and then doesn't modify the MRU). Auto-removing lost files makes me happy; another thing that would work is to move the file to the bottom of the MRU, ensuring that it is dropped on the next new file I open. (In reply to comment #0) This seems to be fixed in 3.4M1. I tried it with a file in the workspace (per what was described) as well as an external file via File -> Open File. CQ: WIND00143398 All, this functionality is working in part already. Deleting a file that was added in the same session will be resulting in the deletion of the file fromthe "recent file" list as well. So far so good, but we still have a bug here, shutting down Eclipse, and reopening it, will restore the recent file list. This time the list will be immune to deleting files from projects, or to deleting projects. Can we comment on this behavior, is a fix easy to make or difficult, what about scheduling? TIA, Ciao, hh (In reply to comment #5) > So far so good, but we still have a bug here, shutting down Eclipse, and > reopening it, will restore the recent file list. This time the list will be > immune to deleting files from projects, or to deleting projects. > > Can we comment on this behavior, is a fix easy to make or difficult, what about > scheduling? Fixing the restart case could potentially cause the undesired activation of bundles because the editor input has to be restored to determine whether it is still applicable as a candidate to be shown in the list or not. (In reply to comment #6) > (In reply to comment #5) > > So far so good, but we still have a bug here, shutting down Eclipse, and > > reopening it, will restore the recent file list. This time the list will be > > immune to deleting files from projects, or to deleting projects. > > > > Can we comment on this behavior, is a fix easy to make or difficult, what about > > scheduling? > > Fixing the restart case could potentially cause the undesired activation of > bundles because the editor input has to be restored to determine whether it is > still applicable as a candidate to be shown in the list or Hm, would this also be true if we - restart, then - delete a file, then - check the file list ? I thought that deleting a file sent a notification a file list could catch, but that's just me not knowing the internals... :( Helmut (In reply to comment #7) > Hm, would this also be true if we > - restart, then > - delete a file, then > - check the file list > ? > > I thought that deleting a file sent a notification a file list could catch, but > that's just me not knowing the internals... :( Yes, it applies because the history basically just has a pointer to some abstract representation of the editor's input. It doesn't have any other information. On a restart, it doesn't even know that it's a file. (In reply to comment #8) > (In reply to comment #7) > > Hm, would this also be true if we > > - restart, then > > - delete a file, then > > - check the file list > > ? > > > > I thought that deleting a file sent a notification a file list could catch, but > > that's just me not knowing the internals... :( > > Yes, it applies because the history basically just has a pointer to some > abstract representation of the editor's input. It doesn't have any other > information. On a restart, it doesn't even know that it's a file. I see. So, the addition we are asking for is making these pointers full files again, such that we get notified about their deletion? Hm, not sure about the implications loading the plug-ins though, I think this is a tradeoff, incorrect recent file list vs. loading time for plug-ins to find out... So, estimating this bugzilla, how are our chances of getting this in? Helmut CQ:WIND00143398 I wouldn't want to get any bundles activated just for validating the recent files list. I'm not even sure whether it's wise to validate / prune the recent files list on startup at all. Consider a file physically stored on a network drive. I launch Eclipse on my laptop while not connected - the file is not accessible, but I don't need it in this session anyways. Back in the office, I launch Eclipse and now I want to see that recent file (and it's accessible again). Looking back to original comment #0, I see two useful improvements: 1) Prune recent file entry when a file is deleted from inside Eclipse. Could the abstract editor representation be enhanced to include an IResource, in order to support this use-case without activating the editor? End users see a single file name, which nicely maps to an IResource logically so if that IResource gets deleted from inside Eclipse, it should be pruned. 2) Improve user feedback when a file is not accessible (project closed, or deleted outside Eclipse, or network not accessible, ...) an empty editor is not a good representation in that case. (In reply to comment #10) > CQ:WIND00143398 > > I wouldn't want to get any bundles activated just for validating the recent > files list. > > I'm not even sure whether it's wise to validate / prune the recent files list > on startup at all. Consider a file physically stored on a network drive. I > launch Eclipse on my laptop while not connected - the file is not accessible, > but I don't need it in this session anyways. Back in the office, I launch > Eclipse and now I want to see that recent file (and it's accessible again). > > Looking back to original comment #0, I see two useful improvements: > > 1) Prune recent file entry when a file is deleted from inside Eclipse. > Could the abstract editor representation be enhanced to include an > IResource, in order to support this use-case without activating the editor? > End users see a single file name, which nicely maps to an IResource > logically > so if that IResource gets deleted from inside Eclipse, it should be pruned. > > 2) Improve user feedback when a file is not accessible (project closed, or > deleted outside Eclipse, or network not accessible, ...) > an empty editor is not a good representation in that case. Martin, I fully agree, if we can get improvement #1 this bugzilla seems to be fixed to me, deletion outside Eclipse is not the problem here, it's more that a platform restart cripples our way to connect a file/project deletion to the "recent file" list.. Helmut (In reply to comment #10) > Could the abstract editor representation be enhanced to include an > IResource, in order to support this use-case without activating the editor? Not directly to an IResource anyway since org.eclipse.ui.workbench does not know about the resources layer. > 2) Improve user feedback when a file is not accessible (project closed, or > deleted outside Eclipse, or network not accessible, ...) > an empty editor is not a good representation in that case. This would be easier to implement as we would just check the existence of the item after the editor input has been restored. If you want to look at the code you can poke at ReopenEditorMenu and EditorHistoryItem. (In reply to comment #12) > > 2) Improve user feedback when a file is not accessible (project closed, or > This would be easier to implement as we would just check the existence of the This approach might be good enough: When trying to restore an editor from the history fails, show a dialog eg "File (...) is not accessible. Do you want to delete the file history entry?" instead of presenting an empty editor frame. Asking the question makes sense when the respective project is just closed, so user might want to open the project and then use the recent files entry. Otherwise the entry is removed "just in time". This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag. |