dnkl changed the topic of #foot to: Foot - fast, lightweight and minimalistic Wayland terminal emulator || 1.16.2 || https://codeberg.org/dnkl/foot || channel logs: https://libera.irclog.whitequark.org/foot
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 :)
<toast> let me get you the links
<toast> enjoy!
<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?
<cbb> as for the "what should I support" part... imo definitely this: https://sw.kovidgoyal.net/kitty/keyboard-protocol/
<bananicorn> Haha exactly what I meant :)
<toast> I do have some complaints about some of kitty's extensions, but the keyboard protocol is legitimately good for sure :)
<cbb> toast: with the keyboard one, or the others?
<toast> others
<bananicorn> So this would be the only required keyboard handling protocol then, if I understand correctly that it's backwards compatible?
<cbb> bananicorn: no, you'd have to support multiple protocols for now
<cbb> probably 3
<bananicorn> I was worried that's the answer, thanks
<cbb> the so-called "legacy" protocol, CSI 27 ~ (xterm's "modifyOtherKeys" mode) and the kitty protocol
<cbb> there are also some small quirks in some terminals
<cbb> for example rxvt and konsole
<cbb> and the linux console
<cbb> it was kind of a wild west until the kitty protocol improved things
<bananicorn> That's lovely, quite the hobby I picked
<cbb> haha, yeah
<cbb> it's not as bad as it sounds though
<toast> I really need to restart on my funny parsing/emitting library for all ECMA48 escape codes (bidirectional)...
<toast> Not having enough time sucks
<cbb> sounds like it'd be useful for a multiplexer
krobelus has joined #foot
<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> indeed there is a way to configure the characters to use, it's VSTART/VSTOP see https://www.gnu.org/software/libc/manual/html_node/Start_002fStop-Characters.html
<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]
andyrtr has quit [Quit: ZNC 1.9.0 - https://znc.in]
alexherbo2 has joined #foot
andyrtr has joined #foot
lbia has joined #foot
amitprakash has joined #foot
<amitprakash> foot is failing to compile w/ `
<amitprakash> render.c:(.text+0x3a62): undefined reference to `wcsncat'` complete log at https://bpa.st/2ICQ
<amitprakash> Wait, is this a C11 issue?
<krobelus> is there a way to pipe the entire scrollback to a shell command?
<amitprakash> That
<amitprakash> That's not it* https://www.diffchecker.com/f4w5WyMm/
<dnkl> krobelus: search for "pipe-" in foot.ini(5)
<krobelus> nice - I've been using pipe-visible, no idea how I missed pipe-scrollback last time
<dnkl> amitprakash: wscncat is provided by libc, check your installation.
<amitprakash> That would be glibc, right?
<dnkl> for most people, yes
<amitprakash> Yeah, not on musl, so that's my only option
<amitprakash> and have recompiled glibc more than a few times now :(
amitprakash has quit [Quit: Client closed]
amitprakash has joined #foot
<amitprakash> Ended up copying libc6.so from working machine to non-working one and that somehow works
<cbb> amitprakash: sounds like it's nothing to do with foot then
<amitprakash> Yep, but somehow only foot was affected
<amitprakash> I have no idea why
<amitprakash> And recompiling glibc brings back the issue =_=
<cbb> maybe because the other things you're compiling don't use wscncat
<amitprakash> ff/clang/gcc etc
<amitprakash> Basically, every other package but foot out of some 600 odd packages (gentoo)
<cbb> amitprakash: I just tried running: readelf -sW /usr/bin/* /usr/local/bin/* 2>/dev/null | grep -w wcsncat
<cbb> ...and I got 2 lines of output, both of which come from /usr/local/bin/foot
<cbb> everything you've said so far points to it being a toolchain/libc issue
<amitprakash> You're right, for me there is just 1 line
<amitprakash> And thats foot
<amitprakash> Sigh, I'm going to try to re-setting up the install from scratch
amitprakash has quit [Quit: Client closed]
<toast> it sounds like a configure bug somewhere, check your use flags
<toast> I'd give more hints but I'm K.O. rn :)
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #foot
alexherbo2 has quit [Remote host closed the connection]
cbb has quit [Quit: WeeChat 4.2.1]