ttyyls has quit [Remote host closed the connection]
ttyyls has joined #foot
sevz has quit [Ping timeout: 260 seconds]
sevz has joined #foot
chiselfuse has quit [Ping timeout: 260 seconds]
chiselfuse has joined #foot
xd1le has quit [Quit: xd1le]
bananicorn has joined #foot
<bananicorn>
Hi there :) If I wanted to write a library that controls and takes input from terminals in this day and age, what should I make sure to support? Are there any documents about this perhaps?
<toast>
bananicorn: you should support the standard escape sequences (minimum), preferably VT100, ideally xterm extensions
cbb has joined #foot
<toast>
most of the standards documents are paid-for, but the European ECMA standards that are just the same thing are open :)
<cbb>
ECMA-48 only covers client to terminal communication though... there's no standard for the other direction
<cbb>
but most of the escape sequences follow the same general format
<toast>
the client to terminal communications generally specify what the expected response format is
<cbb>
there are exceptions to that though... so unfortunately you can't really use a state machine
<bananicorn>
Thanks a lot toast :)
<cbb>
like a terminal would
<toast>
so for instance OSC 52 (my beloved) specifies the response format, basically
<toast>
bananicorn: it's not a 100% everything you need document as cbb mentioned, but it should get you started for sure
<bananicorn>
cbb: I'll keep that in mind, thanks
<bananicorn>
I also saw some new things eg. for handling keypresses or some other things specified in various places like the kitty website, should I ignore these for now?
<toast>
cbb: yeah, and also small utilities, like an osc52 client
<krobelus>
after printf '\x1b[>1u', flow control (as enabled with "stty ixon ixoff") no longer works, is there a workaround?
<bananicorn>
toast: Do I have to be concerned with all the 7 -bit stuff in the standard? The bit notation is also a bit strange, I assume 01/11= binary 00011011?
<toast>
oh the binary stuff is a very weird format yeah, it's basically trying to do hex without numbers
<toast>
01/11 = 0x1b
<toast>
(so yes :) )
<bananicorn>
thanks :) And the 7-bit stuff is not relevant?
<toast>
the 7bit stuff is complicated ^^;;
<cbb>
it's still relevant in that you should probably understand the difference between C0 and C1 controls
<toast>
basically, yeah
<toast>
as long as you output the sequence to say "I'm in 8bit" you can only implement that, iirc
<bananicorn>
Okay, thank you both, will stop the off topic questions now :) (is there perhaps a better channel for this topic?)
<cbb>
you should probably be using C0 ("7-bit") controls, despite POSIX requiring 8-bit bytes
<cbb>
because strictly speaking C1 ("8-bit") controls clash with UTF-8
<toast>
ah yeah, now I remember
<cbb>
and almost nothing uses them
<toast>
I was remembering something being "wrong" there, and indeed, it's the 7bit ones you really want for the most part
<toast>
and yeah there's not really a good channel for this kind of stuff, right?
<bananicorn>
Okay gotcha, I was wondering why I never saw the 8-bit codes in the wild
<toast>
I'd say that if someone minds then it's best to take a break, but otherwise terminal emulator channels are about as good a place as you can find
<cbb>
krobelus: no longer works in what context?
<bookworm>
(we've got ##tty)
<krobelus>
cbb: normally if I run "stty ixon ixoff" in bash, Control-S will pause input echoing, and Control-Q will resume it. If I enable CSI u disambiguate escape codes, the terminal will send something other than 0x13 for Control-S, which is probably why that doesn't work. I tried faking it with "printf '\x13'" but no luck
lbia has quit [Quit: lbia]
hovsater has joined #foot
* hovsater
waves
<toast>
bookworm: oh that's good to know!
<cbb>
krobelus: using printf like that just sends to the tty, not bash's input stream
<cbb>
you could try using some [text-bindings] in foot.ini
<cbb>
i.e. "\x11 = Control+q" and "\x13 = Control+s"
<cbb>
perhaps there's a better (bash-specific) solution that doesn't hijack those keys in every context though...
<cbb>
I'm curious what your use case is for control flow
<cbb>
is pressing Ctrl+s just for demonstration purposes, or is that something you actually use?
<krobelus>
I'm changing fish to use CSI u, to be able to handle arbitrary keys. The shell does not have any code related to flow control, so I assume it's implemented on the terminal side. I do not use Ctrl-s myself but I wouldn't want to break it unnecessarily
<dnkl>
krobelus: it's implemented in the tty driver
<dnkl>
i.e the tty recognizes the "normal" codes sent for e.g Ctrl+s
<dnkl>
I'll admit, this is something I hadn't consider
<krobelus>
dnkl: thanks, that explains it. I'm not sure if there's a way to inject keys into the shell's own input stream
<dnkl>
I wonder if there's anything the shell can do...
<dnkl>
yeah, not sure right now...
<dnkl>
I wonder if it's possible to reprogram the tty to recognize the CSIu instead 🤔
<krobelus>
unfortunately it's a single character only, so I'm not sure
<krobelus>
for other control codes like VINTR it doesn't matter because the shell can send SIGINT themselves. But I'm not sure if there is a way to ask the tty driver to pause input
<cbb>
man termios
<rockorager>
Yeah, has to be a single byte for those termios
<cbb>
I can't recall the exact details, but isn't this line of reasoning conflating 2 different things?
<cbb>
i.e. the bytes used for the line discipline and the terminal's encoding of input?
<cbb>
usually you're not pressing Ctrl+s manually
<krobelus>
the interactive shell already disables echo, and it reads every input byte with a separate call to read(). So for this use case it might be sufficient to call an API to pause/resume input to the shell. Unfortunately it's not that simple, because to know when to resume, the shell needs to receive more input..
<krobelus>
cbb: which line of reasoning? The issue is that due to different encoding of Control-s, the tty driver no longer recognizes it
<krobelus>
I don't think it's a very important issue, AFAICT it's the only thing from c_cc that the shell can't do itself
<krobelus>
also, while external programs are running, fish will disable CSI u again, so flow control will work fine for programs that actually print output
<krobelus>
so it's actually not really an issue, nevermind
<dnkl>
krobelus: just checking... you're using the push/pop feature of the kitty protocol?
<dnkl>
asking since I've seen other applications that don't...
<dnkl>
(they just change it in-place)
<dnkl>
anyway, really interested in seeing how this turns out. I use fish on a daily basis myself :)
<krobelus>
dnkl: yes, but I only ever push one level, and pop every single time an external command is executed (including from bindings)
<krobelus>
so the benefit of the push feature is that we don't destroy whatever our parent processes set
<dnkl>
sounds reasonable. But it also means you're playing nice with fish's parent process (which may be using the protocol as well
<dnkl>
:D
<cbb>
krobelus: I mean, in fish you're only going to recieve \x13 or the kitty equivalent from the terminal for keyboard input
<cbb>
if you wanted to, you could recieve the kitty sequence and emit \x13
erectus has quit [Ping timeout: 260 seconds]
<cbb>
hmm I could be wrong about that... the kernel side of things is kind of hard to find documentation on
erectus has joined #foot
<krobelus>
I'm almost done with the implementation; been using it for a few weeks. Occasionally there was an issue where CSI u was lingering (which hurts when running things like bash) but I hope those are gone now
<krobelus>
cbb: the \x13 would need to be input to the shell, I guess the terminal could control that but not the shell
<cbb>
krobelus: I keep losing track of exactly what point I'm trying to make because there's so many moving parts involved 😅
<cbb>
that point about emitting \x13 was mostly an aside, but you're right
<cbb>
the main point I was trying to make is that it's the kernel that emits the bytes actually used for flow control
<cbb>
what foot emits for Ctrl+s isn't a critical part of that
<cbb>
you're only simulating an unnecessary VSTOP when you press Ctrl+s in legacy keyboard mode
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #foot
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #foot
<krobelus>
I plan to merge with with mixed (modifyOtherKeys + CSI u 5) and later switch to full CSI u because that might need more testing
erectus has quit [Remote host closed the connection]
erectus has joined #foot
alexherbo2 has joined #foot
dustinm` has quit [Quit: Leaving]
dustinm` has joined #foot
alexherbo2 has quit [Remote host closed the connection]