Plots in the terminal (with sixel)

Works like a charm, thanks for the swift and effective reply.

@jheinen If I do the following setup:

julia> inline("iterm", false);

julia> for f in range(0.5, 5, 100)
           ts = range(0, 2π, 1000)
           plot(ts, sin.(2π .* ts .* f))
           sleep(0.0001)
       end

I get the following output, with the plot updating in-place (thanks to the false argument to inline)

However, subsequent plots end up on top of the code previously run:


Until I make a new call to inline("iterm", false) before plotting. When I do that, it “resets”, and for the first new plot, makes sure to push the previous terminal content up to make room for the new plot.

This behavior does not seem ideal, as I assume most users would always want the previous input pushed up in the terminal to make room for the plot. Am I using it wrong, is it something easily fixable, or should I make a bug report?

I apologize if I missed something, but I tried this in the default Julia terminal and nothing shows up?

What do you men with “default Julia terminal”? You need sth like iTerm2 or any compatible app.

1 Like

I changed the cursor movement in GR#master. I hope that fixes your problem …

BTW: the color scheme should now be set automatically (in dark mode).

1 Like

On windows systems, even with a sixel capable terminal,
there appears to be something which disables the output
that is specific to windows.

This discourse post has some discussion and other
links for reference.

I can confirm on master, that the default theme works, and that the plot no longer happens on top of the previous command after inline("iterm", false). Instead, there is now a large blank space above the plots after the first plot (recall that the first plot after inline behaves differently).

I will put the plots into a fold-out, as they are pretty long:

With the second argument to inline set to true we get plain printing of one after the other:

Setting it to false and then making two plots now causes a funny space above it, and overwrites the call to inline with the second argument to false.


So all in all, the behaviour from `inline("iterm")` is the same, and when setting the second argument to false, it is worse IMO. The automatic colortheme is supernice though.

Edit: The command I use (my application is live oscilloscope plotting) is as follows, for testing:

for f in range(1e-2, 1, 100)
          ts = range(0, 2π, 1000)
          plot(ts, sin.(2π .* ts .* f))
          sleep(0.001)
       end

I have currently no idea how to make it more convenient. Overplotting and scrolling is somehow tricky. If you have any ideas, just let me know.

Right. I have no clue, so for now, the best solution I see is to keep the colortheme change, and revert the other one. At least then, it is possible to run inline once before a plotting-loop to get the desired behavior.

print(stdout, "\x1b[s") saves the cursor position, and print(stdout, "\x1b[u") restores it. Also, print(stdout, "\x1b[H\x1b[2J") clears the terminal. I noticed that if I clear the terminal in a loop, the plot flickers, as it is empty for a moment before the new one is drawn and printed. But I do not think that the sixel plots actually overwrite completely, so that the effect without clearing the terminal is perhaps just the two plots stacked on top of each other. But those ANSI codes should at least be able to help with getting the desired behaviour.

Do you believe it is possible to set a non-transparent background for the plot? That should make it possible to overdraw (using the save and restore ASCI codes), and avoid having the plots overlapp.

Note: I believe that these ANSI codes are not supported on the default windows terminal, so there could be platform dependent behaviour. WindowsTerminal should however support it.

It looks like the terminal within vs-code will soon support image display!

4 Likes