Feature request: improved display of output

[marius311]

I'm fairly new to this plugin (although I really like it), so sorry if this has been discussed extensively elsewhere.

I find it very difficult to read the output from evaluated lines in the editor. They're visually kind of in an awkward place (i.e. they all start at a different indentation). Long output requires me to move the mouse, click to expand, and often scroll (since they don't actually expand very far).

Is there some way to improve the output? For example, I find what https://atom.io/packages/hydrogen is doing is really excellent. Could something like that be imitated?

[pfitzseb]

Of course there are ways to improve the output, it's just that someone needs to implement them :)

If I understand you correctly, you'd rather have multiline results displayed below the current line? I guess that'd make Juno more notebook like, which would imo be better implemented along the lines of #63.

Then again, I agree that the results need to be improved a lot for better usability -- I'm just not quite sure how. Here's a proof-of-concept PR for navigating the results with shortcuts though, so if we merge that and make the expansion a bit smarter so you actually see all you need, would that address (most of) your issues?

[ChrisRackauckas]

Should this be closed due to the new fancy rendering of types done by Juno.jl?

[marius311]

Sorry @pfitzseb I realize now I never responded to your question. Yes, more notebook-like would be exactly my suggestion. When you glance at a notebook, its super easy to distinguish what is input and what is output. In Juno, since each output starts at a different "x" position (at the end of the line), I find it very visually disharmonious. Just my 2 cents.

A separate / related thing is, I don't understand why the output box is so small. E.g. in a notebook if I evaluate rand(10,10) I immediately see the entire thing in a output cell. In Juno, I have to 1) click the expand button then 2) scroll around b/c the output is so small. It can become quite a hassle. Why not just expand the output into rest of the window? That would still leave me having to click to expand the output (another reason why I like the "output cell" style), but at least it'd be better, and maybe that part wouldn't be so bad with the keyboard shortcuts you mentioned about.

@ChrisRackauckas, I hadn't been using this plugin lately, but prompted by your message I just upgraded to Juno 0.1.0 / atom-julia-client 0.5.3. Should I be seeing something different about the rendering? I dont notice anything different, but I could be missing something.

[ChrisRackauckas]

Do the same for a custom type. It will show each field and give you an expandable box. I thought that's what you were asking for. (Now that I re-read it, it sounds like that's what you were against).

As for making the array output and stuff bigger, that's good for notebooks, but kind of clogs the screen for code. I think this is for quickly checking parts of output (since otherwise it would cover lots of code). I think there's a good reason to keep notebooks notebook-like and Juno different from that. As stated before: notebooks are good for data, and Juno is good for code. They both work well with what they do, and I think that if you try to make Juno push code around to show big outputs, it will make it harder for actual coding/debugging (like how it's hard to code large projects in a notebook).

[marius311]

Yea, that's totally fair. I had been trying to use to Juno as a replacement notebook (with more convenient "builtin autoreload"), and it was working pretty well for that, but not quite well enough due in large part to this issue and to lack of matplotlib inline plots. For now I've switched back to Jupyter+Autoreload.jl (which is of course missing things like getting to use the Atom editor, autocomplete, etc..), but I'll be keeping an eye on this. Honestly it feels very close to almost entirely replacing Jupyter for me, but ultimately its up to you guys which direction to take it. Anyway, I'll go ahead and close this but I'm happy to give any other feedback.

[cdsousa]

Related: #63 (comment)

[benninkrs]

Things are looking pretty nice, I think. But I find the visual distinction between inputs and outputs (currently indicated by little icons to the left of each cell) not quite enough. Perhaps there could be an option to make the input and output cells have slightly different appearance, e.g. a slightly lighter or darker background?

[marius311]

@ChrisRackauckas, thanks for the discussion here and in the other thread, but just to push back on one specific thing. I definitely get the want to keep things uncluttered, but once I've clicked on the expand button for an output, what possible reason is there to not use all the available space to show me the output? It seems all this does is force me to unnecessarily scroll around a tiny output box. Certainly before I've clicked expand it makes sense to keep things concise, but once I have, why?

[ChrisRackauckas]

It's pretty common for me to already have the box cover up code. I try to get a snippet and use that to double check what the following code is doing (the snippet shows the input, look at the code, see a different snippet for the output). If the box fills the screen, then for one it covers the code, but two it takes the space where another box could open. So I like how the current behavior opens up to an informative snippet, like the REPL show for an array. And in most cases, even the whole screen will be just a snippet of the array (a simple 1000x1000 matrix won't fit comfortably on most screens), so making it show snippets well I think is the most important goal for it (even expanded, since non-expanded shows hardly anything)

I think the general fix would be for it to be resizable (open to this smaller size, and be able to click the bottom right corner to drag it to fill the screen), though that might be asking for a lot.

[MikeInnes]

This is a good discussion and I think there are a couple of good actionable items here:

1. resizable results
2. notebook mode (display results underline rather than inline)

I agree that making results big default would be too much for the common case of quickly checking a small result but I think that between these two features all bases should be covered.

Anyone interested in having these features is welcome to open new issues for them – things with lots of 👍s are more likely to get implemented :)

@marius311 please do feel free to mention any other feedback you have – I'd definitely like for Juno to become comprehensive as a Jupyter replacement.

[ChrisRackauckas]

A separate notebook mode would be interesting. I really don't like mixing notebooks and IDEs since they do very well in very different circumstances, but if there was a button to switch modes I'd be down for that (sounds like what Jupyter lab is trying to do). I think integrating some reports / literate programming thing like Weave.jl, or directly making something like RMarkdown or Sweave would be down this ally.

Notebooks are very sharable though: that's one of the reasons why they are used. A notebook mode would need to store all of the results inline to be saved and shared. Then, if you really want to be a Jupyter replacement, you'd need Github rendering of that file format. That's why I think literate programming would be an easier step in this direction.

[marius311]

Yea I think just (1) would go a long way towards making the current setup easier to use for me. And of course I would love (2). FWIW, in the same way that currently I don't see the need for output saving in Juno, I wouldn't see "notebook mode" as creating that need, for me it's more just about easier visual parsing of the outputs and making use of screen real-estate.

[ChrisRackauckas]

Yeah, I think (2) comes from JupyterLab stepping into Juno's "code instead of data" territory. But I think there's no reason to use JupyterLab instead of Juno if Juno keeps on working on all of the features which are essential to writing large projects, like the debugger, workspace pane, etc. Pairing up with Weave.jl would give an easy entry into literate programming though.