Building an IDE Navigation History
MonoDevelop has a code navigation history. When you switch views, or jump around between definitions, it logs the history, and you can browse back and forth like a web browser. However, it has some major issues -- the history it generates is unintuitive and erratic. It seems like it should be a really useful feature, but in practice is frustrating to use, so I recently decided to give it an overhaul.
Unfortunately, navigation isn't an easy thing to get right in an IDE. It's easy to log too many points. For example, if navigation points are logged every time the user switches between all their open document tabs looking for something, it gets very cluttered.
The most important thing is how it fits into the users' code navigation, so I decided to blog in order to get some feedback on my current thoughts.
In my opinion the following actions should not trigger logging of navigation points:
- Switching through files by control-tabbing or clicking on the tabs.
- Jumping using the search pad or the error pad
- Navigation between items using the document outline or the class browser
- Moving the cursor around with the keys and/or mouse (but this should alter/update the existing nav point)
Whereas the following points should be logged:
- The destination of a "Go to definition" command
- The point that's left behind when executing a "Go to definition" command, if it's not too close to the current point
- A jump to an event handler from a designer
- Locations in which text is edited, though these points should be carefully pruned so that there are no more than one or two per file
In summary, only direct interaction with the document -- and in particular, large jumps -- should be logged.
How will this fit into your coding flow?
Comments
Wrong approach...
Hi Michael, I think you're looking at this from the wrong perspective...
Ask yourself _another_ question which is; "How can I increase the quality of the IDE experience"...?
Then you will get a lot of "out of the box" ideas instead of getting stuck with features nobody wants and none will see the benefit of and you will burn all your energy on...
Maybe one answer would be to have an inline wiki system which reads the mono website where users can inside the IDE actually edit the help wiki system for keywords and such live as the user is typing?
Another example would be to maybe change the default fonts and color scheme in your IDE to something which is more readable?
A third example would be that the IDE could be remotable and able to use with commands from batch files and such for doing scheduling tasks on a server?
I bet that that was the question the developer who first thought of intellisense, integrated help, code completion and such where asking themselves instead of the above...
The above examples where just "brain dumps" and you will probably a lot of way better ideas ones you start practicing this way instead of trying to "copy cat" all the Visual Studio features ;)
Also I think that the "forward and back buttons" are probably among some of the features in VS I use the *LEAST*... :)
We have this feature
We have this feature already, as a near-clone of what VS does (though somewhat broken). I'm trying to make it not suck.
Just because VS doesn't do it well doesn't mean we should discard the idea totally. I'm trying to make it more useful and intuitive by identifying the particular cases where it would be most useful, and making sure those work. I'm also trying to make feel somewhat more like a web browser, so it's more familiar to users.
How about goto definition?
Hi Michael,
I mostly want to use the navigation features when I have used the "goto definition" option in VS.Net. I find this useful because I often want to just have a quick glance at the implementation of a method and then find it difficult to find my way back to the code I was just working on.
Cheers,
James
That is the primary case
That is the primary case I'm trying to make 100% reliable, yes :-)
A Quick Idea
What if you have two navigation histories:
Number 1) would be file-only navigation history to remember previous/next both edited and viewed-only (not edited) files and to allow quickly to switch between them. This would be recorded only when the user switched tabs, etc.
Number 2) would be source code navigation history which is recorded per file. Every interaction (mouse click, go to definition, etc, etc) is recorded as an action.. When the backward history for the opened file is finished then you switch to the history for the previously editied/viewed file (and to the file itself). Switching files when browsing history is not recorded as an action for History 1).
Just a quick idea.
A history
That could be an interesting way to handle a full global history of editing, or a global undo/redo, but I don't think it helps much in the case I'm trying to optimise — making sure that the back button takes you back to where you expect it to. I think a simpler system will suffice.