Minimap next steps

[abe33]

This is mostly to keep track of the things I envisioned for the minimap future and making sure @mehcode is aware of them (and if someone wants to help it's a good starting point).

• Variable height lines support: The idea here is to allow minimap's lines to have an arbitrary height. There's at least two use cases for which this change is useful:
  1. Block decorations support: at the moment, block decorations are totally ignored by the minimap, while it doesn't have any impact on the scrolling part (aside from an offset bug at the beginning this is no longer an issue). But the visible area won't take the block decorations into account. If we had variable height lines it should be possible to add an extra height to the line where the decoration belongs so that the minimap's render reflect what's happening in the editor.
  2. Line label decorations types: at the beginning of the minimap project I started to work on an extension to display a file's symbols (through CTAGS or whatever), the issue back then was that it's possible for many symbols to start at the same line in the file, so there was a lot of stacking/overlay issues to solve before getting something usable (for an idea of what I had in mind emacs' minimap has something along these lines: http://i.stack.imgur.com/y6rfa.jpg). Back to line label decorations, the idea is to attach a text to a line and have that text rendered above/below the line. By having variable height line we can stack up many label for a single line and still be sure that these decorations won't overlap with other decorations defined on following lines.
• Out of bounds decorations: This one is a bit tricky to explain. The thing is, current decorations are rendered on a per-line basis. As decorations are attached to a marker, an editor text range so to say, we're only rendering the part of the decorations that are on the line we want to redraw (when scrolling, editing a line, etc.). This means that a decoration can't take more vertical space than the marker range it's bound to. Let's say we want to render a dot to pinpoint a location in the file, but we want this dot to have a radius of 8px, as of now, we have to, depending on the current minimap settings, define how many lines are covered, extend the marker range to these lines and then have a decoration rendering routine that is able to adapt to all these elements to only render the correct part of the dot that correspond to the line it was requested to draw. And to have tried already I can affirm this is really tedious. The idea here is to have a new custom decoration type, on their own layer, that provides a box defining the space they use in the minimap. With that box, a new decorations rendering routine will be able to detect which other decorations might be affected by a redraw and to restrict the decoration rendering routine to a specific area through the clip method of the canvas API.

[mehcode]

@abe33 Do you think there is merit in doing a full rewrite of the package and requiring the newest Atom version using package.json on release? There are a lot of wins in (start-up) performance and maintainability that could be had. There seems to be a lot of cruft for handling older Atom versions as well.

I think it'd be fun to spike a rewrite to see where we could go with it.

---

Thanks for explaining the direction on those items. Do you have a minimap plugin/extension idea that would help me more clearly see Out of bounds decorations?

[abe33]

There are a lot of wins in (start-up) performance and maintainability that could be had

I'm not sure what kind of changes you're referring to, because I think we've already done pretty much everything that can be done, from moving config, services and view providers in package.json to lazily loading all dependencies that could be lazily loaded, but I'm open to any suggestions on that front.

There seems to be a lot of cruft for handling older Atom versions as well.

That's not that terrible, really, it sures make the code a bit more tedious to follow, but the biggest have been handled already (like removing the shadow DOM) so we should be fine for some time with only little issues to handle. But we can surely clean up some of the mess that have been created over time (I think that the LegacyAdapter can be completely removed, while still conserving the adapter pattern so that we can more easily handle future API changes).

I think it'd be fun to spike a rewrite to see where we could go with it.

Sure, but that's going to be a real hard work, because performances are really critical and current optimizations and improvements have been obtained through hard-fought battles. That's why I'm quite wary of going though all that hassles again to see if a new approach actually gives us a benefit.

Do you have a minimap plugin/extension idea that would help me more clearly see Out of bounds decorations?

Not that I have a specific use-case in mind, but for instance, we can imagine a version of the bookmark plugin that would render a bookmark icon instead of just highlighting the line. Or a plugin that would display an ellipsis icon where code is folded in a document. All this require to be able to render a decoration without being tied to the marker's lines.