This happens both in REPL and while running program from command line. In REPL, without doing anything else, the second command row is filled automatically.
julia> using ImageInTerminal
julia> 61;6;7;21;22;23;24;28;32;42c
When executing a program file (without using ImageInTerminal) from VS Code in REPL, the second row is filled with symbols.
julia> using ImageInTerminal
julia> 1;0c
When a program file contains using ImageInTerminal and the file is executed from VS in REPL, the filled part appears before second prompt.
1;0c
julia>
Last, when executing the program file with using ImageInTerminal from PowerShell, the second prompt is filled
PS C:\Programming> julia program.jl
PS C:\Programming> [?61;6;7;21;22;23;24;28;32;42c
If the program contains user input like readline, the character sequence appears in input position when the program stop to wait.
Versions, I have, are Julia Version 1.11.1 and ImageInTerminal v0.5.2.
Very strange behaviour, and as I’m quite a new to Julia, I don’t have any idea which can cause this.
Looks like your terminal emulator swallows escape sequences. Are you sure it can display images at all? I doubt VSCode’s integrated terminal can do that.
Yes, I’m sure my terminal can display images, but VSCode’s integrated terminal shows them in separate window next to the code. What is more strange, is that the ImageInTerminal seems to work correctly except this extra character printing. It is actually just more annoying than any blocker for work, but would be nice to understand what happens and be also able to prevent it.
That would be your shell (which can matter as well). Primarily, though, I was asking about your Terminal Emulator, which is the graphical program running the shell. Something like Cmder, Kitty, WezTerm, ConEmu, Alacritty, etc. Image support is a feature of the Terminal Emulator, but then potentially the shell might get in the way of that feature (usually they don’t, but I’m not familiar with the situation on Windows). If you run a multiplexer like tmux between your terminal and your shell, that very often causes problems, but I assume you’re not doing that.
Both Windows console host and Windows terminal has the same problem. And still the problem is that the package is printing the character sequence, not that it wouldn’t show the image. But so, this can be Windows related and seems that no one else has the problem.
Are we talking about the unicode approximation for images, like the top picture in
Or the full resolution image via Sixel at the bottom?
Because neither of the terminal emulators you are using has image support, and I’m pretty sure the old Console doesn’t even have unicode support. Actually, Windows Terminal did get image support a few weeks ago: https://github.com/microsoft/terminal/pull/17510. But that’s not publicly released yet, so I’m guessing that’s not what you’re running. So, probably, when the question was asked
the answer was, in fact, “No”.
In any case, I suspect your problems might be solved by using a better Terminal Emulator. I would recommend trying WezTerm.
Actually, we are not talking about unicode approximation of images nor full resolution images via Sixel but the character sequence which appears after using ImageInTerminal. Terminals, which are by default in use in Win11, print some character except the legacy console Legacy Console Mode – Windows Desktop - Windows Console | Microsoft Learn.
The weird looking char you get there is the response of the terminal emulator to a DA1 sequence (most likely the lib tries to determine sixel support with that sequence). Normally the response should be supressed from normal echoing on termios level, so my guess is, that something between your REPL and the terminal does not understand the DA1 sequence correctly and messes things up.
Btw none of the responses you have shown so far indicates sixel support (the char string should contain a “4” for that). If things are properly set up for showing sixel in vscode, the string would have been something like “[?62;4;9;22c”.
