Control rightward growth of trace output

[sdboyer]

The current trace printer does not scale well into having a lot of packages selected - it just continues to grow towards the right edge of the screen. Some strategy for controlling that growth needs to be employed.

The idea I've been playing with thus far is growing a bit towards the right - say maybe up to 6 deps - with the current system, but then showing the number of selected deps on the leftmost side, and keeping the padding constant. So:

(7) | | | | ? attempt github.com/pkg/errors with 1 pkgs; at least 1 versions to try

Transition rows - when we either add a new selection, or pop one off during backtracking - could be tackled through one of two means:

• Rely on a visual effect to give the appearance of rightward or leftward movement, but still operating within a fixed space. I think there might some unicode fun that would help with this, and I had a twitter convo about this a while back
• Just replace the | with left or right-facing arrows

The first approach might look something like this:

(7) | | | | ? attempt github.com/pkg/errors with 1 pkgs; at least 1 versions to try
(7) | | | | | try github.com/pkg/errors@master
(8)  ▌ ▌ ▌ ▌ ✓ select github.com/pkg/errors@master w/1 pkgs
(8)  | | | | ? attempt github.com/golang/protobuf with 1 pkgs; at least 1 versions to try
(7) ▐ ▐ ▐ ▐ ← no more versions of github.com/miekg/dns to try; begin backtrack
(7) | | | | ? continue github.com/pkg/errors with 1 pkgs; 4 more versions to try

Though that box char is pretty obviously awful.

The second approach would be something like this:

(7) | | | | ? attempt github.com/pkg/errors with 1 pkgs; at least 1 versions to try
(7) | | | | | try github.com/pkg/errors@master
(8) > > > > ✓ select github.com/pkg/errors@master w/1 pkgs
(8) | | | | ? attempt github.com/golang/protobuf with 1 pkgs; at least 1 versions to try
(7) < < < < ← no more versions of github.com/miekg/dns to try; begin backtrack
(7) | | | | ? continue github.com/pkg/errors with 1 pkgs; 4 more versions to try

Maybe a hybrid would work well?

(7) | | | | ? attempt github.com/pkg/errors with 1 pkgs; at least 1 versions to try
(7) | | | | | try github.com/pkg/errors@master
(8) └┐└┐└┐└┐ ✓ select github.com/pkg/errors@master w/1 pkgs
(8)  | | | | ? attempt github.com/golang/protobuf with 1 pkgs; at least 1 versions to try
(7) ┌┘┌┘┌┘┌┘ ← no more versions of github.com/miekg/dns to try; begin backtrack
(7) | | | | ? continue github.com/pkg/errors with 1 pkgs; 4 more versions to try

Or maybe it's an unnecessary detail to try to visually represent this information at all, and it'd be better to just show the package count, if anything at all. idk. The goal of the tracing system is to allow the user to follow the decisionmaking path the algorithm is making, in order to really provide full transparency into the process; this specific part of the viz is intended to provide visual cues that make it easier to scan. It's also handy debugging output for when people run into problems, as it provides a clear path that we can follow.

Another option would be to stop trying to make this fit into the rather stringent constraints imposed by terminals, and instead focus on a format for encoding trace data so that, say, a browser-based viz could be triggered with a much richer visualization. Being machine-oriented, such a format would probably be more useful for debugging purposes; as such, we're likely to want to implement it eventually, regardless of what decision we make about trace output here.

[sdboyer]

I should note - there's definitely a bug in the bookkeeping done by the current tracer. I don't know the exact circumstances under which it occurs (or I'd have fixed it), but on larger solves, the indentation starts getting out of sync - that is, the individual ops are more or less indented than they should be, vis-a-vis the line indicating they're being worked on (lines prefixed with ?)