Reworking the display system

[MikeInnes]

I want to suggest a reworking of the current display system that addresses some of its current limitations. To get a feel for what I'm talking about it would be a good idea to try out the Blink.jl display which contains a documented, functional implementation of most of these ideas.

Main Issues

1. No support for multiple inputs: I can't connect IJulia and the terminal to the same running instance of Julia, for example, because all output will be dumped in whichever is launched last. In Juno I avoid this by explicity avoiding the display system, which isn't ideal.
2. No support for mulitple outputs: Ok, there's the display stack, but dumping output in the first possible display isn't useful. You're going to have displays side by side (e.g. Juno, a pop up window and a terminal), and will want to differentiate by (a) input device and (b) type of output (graphical, tabular, etc.).
3. Use of exceptions for control flow: This is more of an implementation detail, but nevertheless it's brittle and causes headaches when developing display types. Media.jl avoids it.

Proposed Solutions

1. The media heirarchy – this is a heirarchy of traits which define e.g. media(::Gadfly.Plot) = Media.Graphical, in order to categorise output types more usefully than the mime-type shotgun.
2. Display pools, which map media traits and object types to displays. This is completely customisable, so you can (for example) temporarily decide you want to explore dataframes or documentation in a pop up window then go back to the terminal when you're done.
3. The dynamically bound "current input", where each input type has its own display pool. By default, an evaluated display call will only "see" the REPL output device if it's evaluated by that REPL. This is again very configurable, so you can give the REPL a pop up window display but not IJulia, or give the REPL access to the IJulia display, or whatever you want.

Media.jl's high-level API is very similar to the current display system, even though the mechanics are very different, so there's no huge increase in user-facing complexity.

The idea of inputs has other advantages; for example, reading input from the user depends heavily on the input device used, but by dispatching on current_input() we can have a single readinput() function serve any possible input device.

Any thoughts, ideas, concerns?

[JeffBezanson]

See also #7959, #8987

[MikeInnes]

To clarify the relationship between this and those issues, the intention is that display will strictly only route output to appropriate display devices, while functions like writemime will continue to do the actual rendering work. In principle the work on both parts should be largely independent.

[StefanKarpinski]

This all sounds quite good to me although I have to confess I don't fully understand the implications. People who might have useful input: @stevengj as one of the original authors of the display system and @Keno as the original author of our current REPL (and one of the more advanced users thereof). Do you two have any opinions on this or know of others who might have useful thoughts?

[ScottPJones]

Why was this closed? I also agree that this sounds like a very good enhancement.

[MikeInnes]

I definitely still think this is a good idea, and would love to get feedback from those two and anyone else who's interested. But it occurs to me that it doesn't immediately need to be part of Base, so it's probably best to flesh out the details as part of the Media.jl package (which I can integrate with Juno esily enough) and keep official support as a seperate step.