Community
Participate
Working Groups
If I make any change to a newly opened Java file, an asterisk appears before the filename in the tab for the editor window, indicating it has been modified. This asterisk (along with any underlying 'dirty' flags on the editor) should go away if the change is undone, but this is not currently the case.
is anyone fixing this? i get bitten by this shallow undo buffer all the time...
hmmm... somehow last comment wound up on the wrong bug...
This happens on all text editors not just Java editors. Currently you have to close the editor and re-open it to get rid of the asterisk. Also it prompts 'filename has been modified. Save changes?' even though there are no changes (due to undo they have all been backed out). I don't consider this an 'enhancement request'. It should be categorized as a 'normal' or 'minor' bug instead. This bug still happens in last week's 2.1 integration (I20030129).
*** Bug 31853 has been marked as a duplicate of this bug. ***
>Currently you have to close the editor and re-open it to get rid of the asterisk. Not true, use File > Revert.
*** Bug 33419 has been marked as a duplicate of this bug. ***
*** Bug 45503 has been marked as a duplicate of this bug. ***
*** Bug 46484 has been marked as a duplicate of this bug. ***
*** Bug 51342 has been marked as a duplicate of this bug. ***
*** Bug 32364 has been marked as a duplicate of this bug. ***
I was going to file it against 3.0M8, but I see it's been around for 18 months. There's no Target Milestone for it, despite the 19 votes...
*** Bug 58519 has been marked as a duplicate of this bug. ***
*** Bug 63907 has been marked as a duplicate of this bug. ***
*** Bug 68422 has been marked as a duplicate of this bug. ***
*** Bug 71264 has been marked as a duplicate of this bug. ***
Seems like a simple change and I am seeing several editors supporting it. The latest one being TextPad. Add a command into the undo/redo queue to turn the dirty flag on if a change occurs and the dirty flag is off. The undo will remove it. If you go past the last saved state during the undo, redo the dirty flag command in the queue
It's been well over 2 years and I'm yet to see this bug resolved (yes, I second Ed Burnette, this is no enh.req, just plain bug). And, File->Revert is no panacea at all; the nuisance this bug causes is particularly irritating while working on half a dozen editors concurrently all of which complain about something changed you don't recall and can't see in undo stack when you want to close them. This has become one of the top voted bugs of Eclipse, but still no attack to resolve it. Why?
This is currently the seventh most voted for bug: http://tinyurl.com/6be3z
(This bug is even older than 2 years. It is a dupe of bug 2281) Kai, this one is the DUPE, but it has most of the votes and CC'ed e-mails. I'll let you decide which one to close.
*** Bug 2281 has been marked as a duplicate of this bug. ***
This item is explicitly mentioned on our 3.1 plan. Still, it is not our highest priority.
This is not a Java editor thing only, it's generic. Besides, bug #2281 seems to be filed before this one (but most people somehow have been forwarded to 21493 in the past). So I think 2281 is more fit to consolidate on unless votes will be lost on the way (btw, do votes really count at all?). I guess this is rooted at some abstract base class(es) and not trivial to fix, but 3.1 is way too late man, we're getting older...
Perhaps not high priority, but very annoying. Seems like the votes for the duplicated bugs are not counted here as well as it does not reflect bug 2281 was opened at 2001-10-10, i.e. 9 months before this one. At least it would be fine if all votes for the duplicated would be shown as well in this bug!
An excellent suggestion from bug 2281 was that this feature should use the quick-diff-against-the-version-on-disk feature to determine whether or not the '*' should be displayed. That would be truer than just looking in the undo-buffer, and since the quick-diff is already working it sounds like that could be less work as well. Regarding votes and duplicate bugs, please keep that discussion to "http://bugzilla.mozilla.org/show_bug.cgi?id=25950".
Quick Diff runs on a low priority thread in the background. The dirty bit has to be up-to-date all the time. Not to mention its an expensive operation and may be tuned to ignore whitespace changes, etc. I'm surprised with as many CCs as there are that no one has tried to provide a patch, or at least understand why the fix is not simple. I took a look myself. It looks like AbstractDocumentProvider becomes dirty the first time the document is changed. So maybe if the provider allowed the dirty bit to be set explicitly, then it could be based on the undomanager's state. So if the undoStack is empty, then the document is clean, unless the undo limit has been exceeded and commands have been purged at line 131 in DefaultUndoManager.
If the document has changed, it has changed. No different action for whitespace differences! If you open documents like bitmap files in eclipse, they are "dirty" the moment they become visible ... this might be more difficult than checking the undo buffer or do a "quick diff", which might be useful for text files.
About how many are on this item, I would say, they are not all of them. Because, even after duplicating you don't get an additonal notification nor are on the CC nor are on the Vote-list. Yeah, it's a Bugzilla-Issue, but I wanna only mention it. About the Undo: I personally do not understand, what it should make sense to compare with the file on disk. The dirty-flag should be set only from the point of view of the Editor in memory. The rest is non-sense (for me). If the UndoBuffer was already exceeded, I could quite live with the fact, that although the UndoBuffer is empty, the Dirty-Flag will never be restored again. It only matter about how large the UndoBuffer will be resp. is. If it is e.g. 25 commands, and you have made 30 changes, then I do not see it useful to reset Dirty-Flag after 25 undo-changes. The remaining 5 changes could never be told if they are undone or not.
I read the '*' to mean "the in-memory buffer has the same contents as the file on disk", or conversely, if it isn't there I interpret it as "saving this buffer won't change anything". From that point of view, what changes have actually been made to the buffer doesn't matter much. However, it might be that the quick-diff isn't suitable for this purpose for some reason, and it might also be the case that the '*' means other things to other people than me. But for my purposes, using quick-diff for this would be good. YMMV of course.
Correction: I read the '*' to mean "the in-memory buffer's contents is different from the contents of the file on disk". Duh.
Only out of interest: How do you change a file, while it is in Eclipse open? At least under Windows it is not an easy task to perform. And if you do it via tricky way, you are responsible for it. i.e. as long as no overflow of the UndoBuffer was done, the result to empty the UndoBuffer should be the same as the file-content. If you see another way to have a difference it would be fine to know about - as long as the UndoBuffer did not exceed.
I read things like when emptying undo map then * should vanish again. But this should be always the case. Because the saved state should not be undomap == 0! if i do this: open a file (no *) make one change (*) make a second change (*) save a file (no *) make a change (*) undo (no *) another undo!! (*) (now i reverted to the state BEFORE the save!! so it is modified again...) a redo (no *) (the save state..) This is how it should work. How i make my undo/editor behaviour in the app i am/have written.. So save should not clear undo buffer.
To answer Leopolds Questions: Changing a file that is open in Eclipse using an external tool isn't a special operation in any way, at least not on Linux. If I change something with an external tool, Eclipse pops up a dialog saying that the file has changed on disk and asks me if I want to reload it. The case when the quick-diff vs the undo-buffer algorithm differs is: 1. Open a file. 2. Type "foo". 3. Hit backspace three times to remove the "foo". Quick diff now says that the file hasn't changed The undo buffer says the file has changed. I think quick-diff is correct and the undo buffer is wrong in this case. I don't know what quick-diff really compares against, but for the '*' the best thing would be to compare against the most recently loaded / most recently saved version of the file. If the file on disk is changed using an external tool, we'd still prefer to compare against what Eclipse thinks the file on disk looks like, not to the on-disk truth.
Johan, In our GEF implementation, editor is clean when SavePointer == StackPointer. When commands are purged, save pointer is decremented until it becomes -1, which means the save location has been purged and can't be reached anymore. So we added API like: void markSaveLocation(); /*returns true if the current state is no the last saved state*/ boolean isDirty();
*** Bug 76618 has been marked as a duplicate of this bug. ***
*** Bug 81549 has been marked as a duplicate of this bug. ***
*** Bug 82794 has been marked as a duplicate of this bug. ***
*** Bug 39753 has been marked as a duplicate of this bug. ***
*** Bug 87472 has been marked as a duplicate of this bug. ***
Fixed in HEAD. Available in builds > 20050420.
If I drag a file ( .txt for example) to eclipse and open it,then for this file the bug is still there.
(In reply to comment #40) > If I drag a file ( .txt for example) to eclipse and open it,then for this > file the bug is still there. See bug 214351.
