mintty supports sixel

[johnnychen94]

It seems that the TTY response from the sixel control sequence is directly printed on mintty terminal; The result "64;1;2;4;6;..." is expected to be captured by query_terminal. I'm not sure what's the underlying issue here as I'm still new to Windows programming.

https://github.com/johnnychen94/Sixel.jl/blob/d34028488c8417aa6e10bb6e0ebe18c81d41e44b/src/Sixel.jl#L49

[t-bltg]

Maybe use IOCapture as a fallback when TerminalTools.query_terminal fails ?

[devel-chm]

I was trying to get Sixel.jl working for a julia sessing in a cygwin xterm
runningon win10 and a mintty window running on win10 as well.

I first generate the escape sequence for the primary device attribute (DA)
query output to the sixtest.txt file. The escape sequence for the secondary
device attribute DA placed in sixmore.txt. Using the bash shell in cygwin
for both.

This is what I got:

echo -e '\e[0c'  > sixtest.txt

# On xterm in cygwin
cat sixtest.txt                 # don't display the ^[[?  (not in raw mode)
63;1;2;3;4;6;9;15;16;22;28;29c  # xterm in cygwin
63;1;2;4;6;9;15;22;29c          # mintty in cygwin/win10

echo -e '\e[>0c' > sixmore.txt

cat sixmore.txt
19;370;0c                       # xterm in cygwin
77;30502;0c                     # mintty in cygwin/win10

# On windows console
cat sixtest.txt
^[[?1;0c                        # seems to correspond to VT101 DA

cat sixmore.txt
                                # no output visible for this

It shows that both the cygwin xterm window and the mintty window
produce output indicating that sixel graphics is supported (attribute
response of 4).

BUT

When I run a julia-1.8.5 instance in any of the three types of terminal
(cmd console, xterm, or mintty) the result is always the same as the
windows console alone:

shell> cat sixtest.txt
shell> 1;0c

The problem seems to be that julia on windows assumes "windows-ness"
and thus short circuits actually sending the escape sequences in raw
output to the terminal window. A solution would be for there to be
some way to actually do a raw output on windows rather than whatever
seems to be quietly substituted.

I'm not versed enough in the platform issues and libuv to understand
what was done and how to fix it.

Other experience with porting software to windows platforms
suggests that the proper approach is to query directly for the
capability that is needed and not second guessing things by
using platform information.

NOTE: I tried using IOCapture but it has the same problem
(presumably because it uses julia).

[devel-chm]

Example for using bash to query terminal device attributes are here in
Julia Discourse.

[kagalenko-m-b]

I encountered this bug as well. There appears to be no way to use Sixel directly in any windows terminal available. It is possible to first save escape sequences in a file

 open("out.sixel", "w") do io
             sixel_encode(io, img)
end

and then cat out.sixel both in mintty and msys2 shows the picture, so the terminal is not the source of the problem. If I hack the source so that Sixel.is_sixel_supported() always returns true, then escape codes do get dumped into the terminal, but no image is displayed. So the problem seems to rest with Julia.

[johnnychen94]

The main usage of is_sixel_supported that I know is in ImageInTerminal.
Maybe we should use an environment variable, e.g., SIXEL_SUPPORTED to indicate ImageInTerminal to use Sixel.jl as encoding backend? (But I personally hope we can fix the terminal issue somewhere in Julia so that is_sixel_supported get reliable result)

cc: @t-bltg

[t-bltg]

I think it would make sense to override the behavior of is_sixel_supported by using an environment variable, in the context of windows failure to query the terminal support of sixels (I don't use windows, so I cannot really help fix this).

[kagalenko-m-b]

I think it would make sense to override the behavior of is_sixel_supported by using an environment variable,

Function is_sixel_supported() seems to work correctly. It's interaction of Julia with terminal on windows that is the problem. For instance, if you save a picture in out.sixel and do cat out.sixel from the terminal directly, it shows
the picture, but if you escape to shell in Julia by semicolon and then cat out.sixel , you'll see the raw codes.

This bug is not in Sixel or ImageInTerminal, in all likelyhood.

[devel-chm]

Technically, is_sixel_supported works since the problem is that the julia REPL appears to
overlay the underlying terminal (for the windows OS) with a console rather than using the
terminal via stdin/stdout/stderr and the native capabilities. The windows console does not
support sixel graphics.

Sixel.ij works to encode an image. You just cannot cat image.six inside a julia terminal
session in the REPL sh mode, for example.

[kagalenko-m-b]

julia REPL appears to overlay the underlying terminal (for the windows OS) with a console rather than using the terminal via stdin/stdout/stderr and the native capabilities.

Maybe this issue should be raised in core Julia repository?

[devel-chm]

My julia discourse post shows what I tried on win10.

It would be nice to check on WSL2 to determine
if the detection logic shows WSL as unix and works vs seeing the underlying windows 10 OS and fails
in the same way.

Any takers?

[kagalenko-m-b]

It would be nice to check on WSL2

How would that help to fix the issue?

[devel-chm]

Checking WSL2 would give more diagnostic information and
enable that as a possible work around---not a solution.

[kagalenko-m-b]

You just cannot cat image.six inside a julia terminal session in the REPL sh mode, for example.

Of course, I can:

shell> cat out.sixel

That shows the picture on linux in supported terminals, but not on Windows

[devel-chm]

Right, not on Windows which is the context of this entire github issue.

[kagalenko-m-b]

This issue should be raised in Julia repository, Sixel.jl is clearly not at fault.

[johnnychen94]

It would be great if someone with enough knowledge on Windows terminal behavior can open a generic-enough issue on the Julialang/julia repo -- if it's only about sixel then people might quickly lose the interest. In the meantime, I'll keep this open as a tracker.