Move coverage markers slightly to avoid conflicts with R# jewels

Sometimes R# puts its lightbulbs etc. over the top of NCrunch markers. Seems there's greater chance of success asking for NCrunch to move them slightly than having R# do it ;)

The big question would be where to move them to ... if they go further to the right, they may interrupt the code .. if they go further to the left, a new tray will be needed to hold them :)

How about taking R#'s approach - move to the left, but perhaps with some transparency unless the mouse is nearby

Right now it's as far to the left as it can be on the text pane - so this would take some work. I'll look into it.

D'oh sorry late night writing - I meant right. Anyway, think I've made my point :)

Remco wrote:The big question would be where to move them to ... if they go further to the right, they may interrupt the code .. if they go further to the left, a new tray will be needed to hold them :)

I don't think a new tray is a bad idea you know. I guess you're worried about screen real estate - if so I don't think it's an issue. It's a compromise, but on balance I'd rather it didn't interfere with other tools. I've gotten into the habit of clicking onto another line to read NCrunch mouse-overs when the R# lightbulb is clashing, but it is a fiddle.

Given the power-hungry nature of CT tooling I expect most people are running on powerful computers, and most powerful computers are probably wide-screen if not multi-monitor setups. I'm loving NCrunch, but I only run it on my desktops. Even if people do run it on laptops, those laptop screens are getting higher res all the time, and it's not hard to unpin all your docked tool windows anyway - its what I do and it's fine. For all the extra information I'm getting from NCrunch, I'm very happy to sacrifice the necessary width.

Actually screen width wasn't my biggest concern around this - I'm more concerned about implementation time and performance implications. With the markers embedded into the text, I'm able to make use of built-in features in Visual Studio that allow the marker positions to be maintained along with the text. This reduces the effort needed to synchronise the marker positions with the source code while the code is being changed. Spending time on this task would mean less time would be spent on higher value features (i.e. making the engine work 4x faster!) :)

Well, personally I've no complaints about performance at the moment - the heuristics of only running tests that need be run seem to work well and I've not suffered. The machines I am using though are quite fast (a Core i7 2600 @ 3.4Ghz and a Core i7 2700K @ 4.8Ghz) with plenty of memory. (I'm currently running solutions with tens of thousands of lines of code and many hundreds of unit tests.) Obviously others milleage may vary.

That said, I think it's quite telling how far you've come with this product that this is my No.2 complaint about NCrunch! As it goes, it's only a minor annoyance and certainly one I can live with.

As an aside, from personal experience it can be all too easy to second guess the needs of your audience: You may be doing this already and I've missed it, but how are you measuring the priority of feature requests? A votable issue list would be nice... Of course, it's your product and you may well prefer to focus on the "interesting" problems. - I know I probably would! :) I bet the marker stuff is a right pain in VS.

Alternatively, you could go with the idea I posted elsewhere about getting into business with Jetbrains. ;)

Keep up the awesome work!

Thanks! Your feedback is very welcome. The way I prioritise features takes a range of factors into account, but generally speaking when more people request a feature it does go much higher on the list. Most of the constraints are usually around performance and stability, as these are very easy to sacrifice in the lust for adding more features. They are also the two least interesting things to work on :)


Cheers,

Remco