Feature Request - Minimap ala SubLimeText

[jscheller]

Hello -

I've often wished for a feature like the "minimap" one described here...

http://www.sublimetext.com/

...that allows you to scroll around a very high level view of the source file and use it to find what you need to edit visually based on the "flow" of the code. At least for me, I think this would often be more efficient than using search or bookmarks to jump to specific places in a source file.

I realize this probably isn't a quick/easy addition, but I'm already looking forward to SlickEdit 2009...   

Jim

[chrisant]

The minimap feature looks like a very nice idea...but after downloading Sublime to play with the minimap, I don't like Sublime's implementation of the minimap:

• In a file 505 lines long, the minimap showed the full file.  In a file 816 lines long, it did not show the full file:  it showed a large subset of the file, but pressing Page Down (etc) scrolled the minimap in a somewhat jarring incremental way.  I don't know offhand exactly how I'd want to see the scrolling work in a minimap, but this isn't how.    (I didn't narrow down where the cutoff is for how long a file needs to be before the minimap needs scrolling).
• The minimap is too washed out in the several cpp files I opened (more so than the sample images on the web site), as if the image scaler needs tweaked to keep more color while merging adjacent pixels during scaling.
• You can't click on the minimap to move to that part of the file.  The first two points I can understand.  I figure this third point is just something they haven't gotten around to implementing yet, as it seems quite simple to do.

The minimap is a neat idea, but needs some more UI polish.



By the way:  I fervently wish SlickEdit had a bunch of predefined color schemes to select from for the color coding.  SublimeText has several predefined color sets to choose from, which reminded me of my desire for this -- however although many of them are pretty, there is no way to customize them, and most seem impractical (bright orange on black for function names?  dark gray on black for comments, really?!).

In SlickEdit's color coding configuration dialog(s) I see an Import... button, and I'll look into how to use that, but I wish it were (a lot) easier to change the color schemes in SlickEdit.  The isolation between settings for each language is very nice, but if you want to change the default colors you have to do it individually in a ton of places, once for each language.  It's such a daunting task (even with an Import... button) that I resigned myself to using the default colors in SlickEdit even though they're really not what I'd like to see.  They're decent, though, and I can live with them, but in such an ultra-configurable editor as SlickEdit is I had assumed color schemes would be easier to swap around and "try out" on my way to finding "the perfect" color scheme.  (I didn't even port the color scheme I've been using for the past 20+ years, because it seemed like such a pain).

[Ivan N. Zlatev]

By the way:  I fervently wish SlickEdit had a bunch of predefined color schemes to select from for the color coding.
...

This has been available probably for ages now. Check the screenshot attached

[hs2]

I've also started a user scheme thread here back in 2006
There quite a few well designed schemes available there.
HS2

[ScottW, VP of Dev]

I like the idea of the minimap, particularly if it was used to show where errors, matches, etc. are located. As a code browsing tool, I don't think it's that strong. For a file of any reasonable size you wouldn't be able to read the text.

That's were Selective Display is more useful, allowing you to collapse blocks of code so you can see more of the file. You can also use the Defs tool window and Class tool window to view a kind of outline of the file. Right-click in either and you can select "Sort by Line Number". Now you can see an ordered list of the elements in your file. Double-click on any item to navigate to that location. SlickEdit automatically highlights the current element as you position the cursor within the editor window.

[jscheller]

I like the idea of the minimap, particularly if it was used to show where errors, matches, etc. are located. As a code browsing tool, I don't think it's that strong. For a file of any reasonable size you wouldn't be able to read the text.

I don't think the goal is to be able to read the text... As you've pointed out, it'd be too small to be visible and even if it was marginal trying to read text mashed down to aliased 4 point font sounds like a recipe for certain eye strain. It's definitely not a tool for browsing/editing the actual code.

Really what I think the intent here (or at least what my idealized perception amounts to) is a navigation tool. There are a lot of times I'm editing files that have a certain visual structure to them and I find myself scanning this structure not by reading but by scrolling ("Click and furiously drag the scroll bar thumb up and down... Ahhh... there's that bit..."). I my minds eye, doing something like this on a zoomed-out view of the file, even if you can't read the actual text, would be somewhat more efficient.

This sort of tool might also provide another view of code that you just can't quite get at the full "100% zoom" view a conventional editor gives you. A good example is when some code has been maintained to death and crept up in size... I often zip right into the middle of some function to make a change using "Find" to get there, and over time you wind up with a function growing to hundreds of lines of code... If you had some zoomed out view of a file, it'd probably give you some immediate (obvious) visual indication of when refactoring becomes more important... All the sudden that 500 line function taking up 80% of the source code file is in your face...

[chrisant]

I think a minimap is a navigation tool, not a browsing too.

The eye is good at finding patterns (often even where there are none ) and although I may not know the line number I'm looking for, or where the section has moved to while other people have inserted/deleted/moved lines in the file, but often certain chunks of code have a distinctive "shape".

That said, I don't think it's a strong navigation tool.  It simply doesn't scale well, even with some image processing tricks to boost color preservation when the image is scaled down very tiny.  For example, in a 500 line file it will work ok, but in a 2000 line file it simply won't work well:  the tallest monitor I have is only 1200 lines tall, so we're talking less than 1 pixel per line.  I like the idea of a minimap, but I just don't see how to fix the design problems (I fear they are inherent).

It would probably be a better use of time to investigate ways to make use of Selective Display to help with navigation.  E.g. maybe Selective Display could show statistics about how much stuff (not necessarily just a simplistic line count) is hidden in a collapsed node, or show a heat map of sizes of code blocks in a file, or so forth.

[chrisant]

By the way:  I fervently wish SlickEdit had a bunch of predefined color schemes to select from for the color coding.
...

This has been available probably for ages now. Check the screenshot attached

Shazam!  (HP++)  Thank you very much!  The dropdown has been staring me in the face and snickering at me. 

[ScottW, VP of Dev]

Yes, the human brain has remarkable pattern-recognition ability. I worked on a project for NASA and met a guy who watched binary telemetry data displayed on an old green-screen monitor. This was WAY before The Matrix came out, but it was like a scene from that movie. He'd be staring at the screen and then say, "uh oh". If you asked him, he couldn't tell you what went wrong but he knew when the pattern didn't look right. He was concerned that the new system would not allow him to recognize when things went wrong.

I do believe that concept can be used to help navigate code, but I'm not convinced that is a powerful enough mechanism to prioritize it up over other changes. As always, I'm willing to be convinced by an outpouring from the community. I also think it takes up more horizontal space than most users would be willing to give it.

[jscheller]

I do believe that concept can be used to help navigate code, but I'm not convinced that is a powerful enough mechanism to prioritize it up over other changes. As always, I'm willing to be convinced by an outpouring from the community.

You've got one vote from me. Even if you don't get a bunch of other folks jumping in, I hope it'll stay somewhere on the undoubtedly long list of possible future enhancements there.

I also think it takes up more horizontal space than most users would be willing to give it.

With bigger widescreen monitors these days, I'm finding I've got way more extra horizontal space compared to vertical... I feel like I'm constantly on the prowl for fonts that have less vertical dimension to them just so I can fit more lines of code on the display.

In my coding dreams, I see one of those three-monitor setups with 24" displays rotated vertically... 

[jimlangrunner]

..He'd be staring at the screen and then say, "uh oh". If you asked him, he couldn't tell you what went wrong but he knew when the pattern didn't look right...

Yep.  Like that.  It's the pattern of the code.  Colors blend, lines merge, but the pattern remains as long as it's not scaled too far.   <pipedream>Of course, a sliding window, kind of like the GIMP let's you zoom to a place on an image, a sliding window could zoom to a place in the code </pipedream>

I do believe that concept can be used to help navigate code, but I'm not convinced that is a powerful enough mechanism to prioritize it up over other changes. As always, I'm willing to be convinced by an outpouring from the community. I also think it takes up more horizontal space than most users would be willing to give it.

If the minimap were a self-hiding window, the footprint would be negligible, and would be handy when needed.

Please, this is NOT a vote in favor, merely a counter-argument in favor.  It would be a nice feature, but I don't see it as a high priority for me.  But I can see the algorithm forming in my head.  (make it stop!)

Best,
Jim

[Steve Black]

If the minimap were a self-hiding window, the footprint would be negligible, and would be handy when needed.

Nice...   

So:

• map window pops up/over/in on button-press/context-menu select/hover.
• map window can consume as much screen/window space as needed
• map is scaled as needed to represent full text width in proper colors (fore & back)
• map length can overflow with scroll, can column wrap in width-expanded window, or both (user option)
• cursor is edit window-shaped frame around text to be displayed on click/keypress
  
  • (splits across column boundaries?)
• cursor moves with mouse or cursor keys
• context area (tooltip?) displays first n non-whitespace characters on top row of cursor frame target

With the right design this could be very useful.  I've certainly worked on many a file that could have benefited from it.

I've never thought of this before but I'm going to have to vote for it.  Scott, consider this my outpouring.

"MiniMap '09"   

[SlickEdit Support]

Or, you could try binding Ctrl+PadPlus and Ctrl+PadMinus (or whatever works for you) to the SlickEdit commands wfont-zoom-in and wfont-zoom-out respectively.  A couple/few quick taps and you've zoomed out to get the overview, a couple/few quick taps and you are back to a readable font size.  (Tools --> Options --> Keyboard --> Key Bindings)

[jimlangrunner]

Or, you could try binding Ctrl+PadPlus and Ctrl+PadMinus (or whatever works for you) to the SlickEdit commands wfont-zoom-in and wfont-zoom-out respectively.  A couple/few quick taps and you've zoomed out to get the overview, a couple/few quicktaps and you are back to a readable font size.  (Tools --> Options --> Keyboard --> Key Bindings)

Now that's a neat trick.  Those keybindings were already taken, but others work as well, and it really does help.  hp++

Jim.

[Lisa]

Or, you could try binding Ctrl+PadPlus and Ctrl+PadMinus (or whatever works for you) to the SlickEdit commands wfont-zoom-in and wfont-zoom-out respectively.  A couple/few quick taps and you've zoomed out to get the overview, a couple/few quick taps and you are back to a readable font size.  (Tools --> Options --> Keyboard --> Key Bindings)

More info in the Did You Know board here: http://community.slickedit.com/index.php?topic=3119.0