Community
Participate
Working Groups
Previous Location suffers from many not-very-useful behaviours. - records top of newly-opened files as 'important location' - misses edits at widely separated positions in same file, as important locations - re-opens files which had been opened briefly, experienced no (significant) cursor movement, experienced no editing as 'important location' - records minor cursor movements within a few lines as 'important location' I experience the usefulness of this feature as about 30%. 70% of the positions it takes me to, weren't of any significance and just confusing. The positions which were significant, seem to be lost in the clutter or not show up at all. Also if I'm not interested in the file, I don't want it to stay open. The horizontal editor tabs are useless enough when I have 10 files open, without X number of uninteresting extra files opened as a 'clutter' side-effect of navigation which didn't find where I wanted to go anyway. It appears the algorithm needs a complete re-write, to reflect on a user-level which positions and actions are significant to the users. Because it seems currently grossly non-reflective of these. (the poor usability of horizontal Editor Tabs, and minimal effective usability of Prev Location, are a constant gross impediment in my Eclipse work. I have to use the caret list or open Resource, *every time I switch files*, giving a typical 65% productivity impairment in the critical area of context switching. this is calculated by 6 - 7 cognitive actions required to use the caret list, or even attempt Prev Location usage - which attempt 70% is ineffective; versus 2 cognitive actions when a clearly visible Editor Tab can be seen. and this is at a crucial point of transferring one's train of thought, to a different file... these extra steps or failed attempts to find with Prev Location simply derail this. i find this just so bad, it's like trying to type on a keyboard with the enter button located behind the computer... )
Okay, as near as I can figure (by putting in printlns), a new location is created when: + A file is opened. + A compilation unit is clicked in the Outline view. + F3 or some other navigation command is used. I assume that by "minor cursor movements" you mean using navigation commands to move around the file, but that those navigations commands don't actually move that far within the file (i.e., the old location remains visible). In general, I don't think we're looking to change NavigationHistory at this time. If you're interested in writing a patch to improve what we already have, I would be interested in seeing it.
Moving Dougs bugs
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
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.
