euporie-console not working

[mukund109]

See screenshot. Not able to type anything. Euporie version 2.0.2 GNOME Terminal

[joouha]

Which version of GNOME Terminal are you using? I've just tested on GNOME Terminal 3.44.1, and it works as expected.

The text you're seeing before the prompt is an escape sequence for detecting kitty terminal graphics support, and it shouldn't be printed to the terminal - but I have seen some old VTE base terminals print it.

Do you get the same thing in other terminals? Does the cursor move if you try to type something?

[jerch]

@joouha Proper fingerprinting of the kitty image support is quite tricky, mainly because it relies on APC escape sequences, which are lousy to not supported by several terminals (resp. their parsers). Most of those "defect" terminals would just print things to the output, thus you might get away by doing a CPR afterwards and fixing cursor moves and falsey output manually.

[joouha]

Thanks @jerch - I've done some playing around, and found that sending the following sequences works quite well:

• Save cursor position (\x1b[s)
• Kitty detection APC (\x1b_Gi=4294967295,s=1,v=1,a=q,t=d,f=24;AAAA\x1b\\)
• Restore cursor position (\x1b[u)
• Erase line right (\x1b[2K)

This leaves the cursor in it's original position and leaves no trace of the APC code.

@mukund109, I've implemented this in v2.0.6 - I'd appreciate it if you could test this and let me know if that fixes the issue for you.

Thanks!

[jerch]

@joouha Yep good idea with the cursor saving. I only see 2 minor issues linked to the whole idea (prolly not showstoppers):

• The test should run on a "clean slate" terminal, prolly very early after switching to alternate buffer (assuming euporie does not use the normal scrolling buffer). This way it cannot destroy accidentally previous terminal buffer content on falsey printing to right side. If done late (right before first image usage), the cursor might be in the middle of already written terminal cells destroying important output. Not sure to what degree you control the screen state internally and can easily restore from those screen hazards.
• Current cursor position minus COLS should be wide enough to hold a falsey printout from the test sequence (39 cells if counted correctly), otherwise your line erasing wont reset all rubbish (as the terminal already might have advanced to the next line, ehm if DECAWM is set - geez so many ifs and elses...). Again if you have quite advanced control of the screen state this might not be an issue at all for euporie.

[joouha]

Currently I run all the terminal queries before any output is generated, so should be OK on the first point.

The line wrapping I hadn't thought of, but will ensure it's disabled before probing the terminal (currently it gets disabled afterwards).

Thanks so much for your help!

[joouha]

I think this is fixed now, please open a new issue if you're still experiencing problems with euporie-console