[BUG] Non-interpreted ANSI sequence printed in the terminal about pytermgui

[bczsalba]

The sequence actually comes from your terminal! Basically, PTG writes a pixel dimension request, and the terminal has some time (I think 0.1 seconds) to respond. The timing is there to solve an issue where PTG would try to catch sequences that are never written, so it would just get stuck on an endless getch call.

The sensible thing to do here would be the only query the dimensions on demand, so it's not done when not needed. The timeout could also be a bit larger.

[bczsalba]

Aw heck. The sequence is the response to use querying the terminal's foreground color, which we need to create an accurate screenshot. Gonna try to look into why the response doesn't get captured.

[bczsalba]

That's alright! Let me know if you ever run into it again.

[pawamoy]

I see, thanks for the explanation 🙂
I'd be totally fine with being able to configure the timeout through an env var if this is something you'd consider.

[bczsalba]

Could you check on the latest commit? This should be fixed now.

[pawamoy]

Just checked (pip install using master branch, i.e. commit e523f70): seems to be fixed indeed! Thanks!

[pawamoy]

Hello, I'm having a similar issue again. When I run the following snippet in a subprocess, it prints an ANSI sequence and then gets stuck:

from io import StringIO
import pytermgui as ptg

terminal = ptg.Terminal(stream=StringIO(), size=(80, 16))
ptg.set_global_terminal(terminal)
with terminal.record() as recorder:
    recorder.write(ptg.tim.parse(ptg.highlight_python(code)))
print("before svg")
svg = recorder.export_svg(inline_styles=True)
print("after svg")

Output when running it:

before svg
^[]10;rgb:e4e4/d9d9/c6c6^G

Note that this happens in a mkdocs subprocess, and then in an exec call (I'm working on markdown-exec 😉). Not sure if it really matters.

Do you know to what corresponds this ANSI sequence ^[]10;rgb:e4e4/d9d9/c6c6^G? (and why it's printed on screen?)

[bczsalba]

Hey, is this still an issue? I'm not sure if anything related has changed since then, but in case things are still broken I can look into it.

[pawamoy]

Let me check, I had disabled pytermgui in the meantime :)

[pawamoy]

Still happens, but only when I run the mkdocs command through my task runner (duty) it seems (didn't test extensively), so don't bother too much. I'll try to isolate the real cause when I get some time 🙂

[bczsalba]

Ever figure it out? :)

[pawamoy]

Nope, sorry 😕

[pawamoy]

So it's still happening. The crux of the issue is probably that I'm capturing the output, preventing PyTermGUI to read it it itself when querying the terminal for the foreground color, so it blocks. The sequence I'm seeing: ^[]11;rgb:1212/1919/0d0d^[\. I'm capturing output at the file descriptor level: https://github.com/pawamoy/failprint/blob/3d1317dc9f663719bab381c1f39fe54cda308d3f/src/failprint/capture.py#L78.

Ideally, PyTermGUI wouldn't block thanks to a read timeout or something 🙂 I'm trying to think of something for disabling it when capturing the output (when I'm checking if the docs build correctly), but I don't see yet how I could disable just a paragraph in one my Markdown pages 🤔

[pawamoy]

OK found a workaround, I'm adding this at the top of the PyTermGUI snippet:

import os  # markdown-exec: hide
for envvar in ("PYTHON_VERSIONS", "CI", "MULTIRUN"):  # markdown-exec: hide
    if envvar in os.environ:  # markdown-exec: hide
        print(  # markdown-exec: hide
            "PyTermGUI blocks when querying the terminal foreground color with an ANSI sequence "  # markdown-exec: hide
            "because we capture the output ourselves through `failprint`, "  # markdown-exec: hide
            "so this gallery example is disabled in CI.",  # markdown-exec: hide
        )  # markdown-exec: hide
        raise SystemExit(0)  # markdown-exec: hide