291–300 of 323 posts
Earlier quoted context omitted.
>There are no benchmarks in which I've found Alacritty to be slower. It's actually very, very slow. https://danluu.com/term-latency/
I have a hard time believing this because it doesn't make sense that Hyper, an electron-based terminal emulator, would be faster than Alacritty.
Earlier quoted context omitted.
Theres no way you can build a terminal emulator without a PTY and still expect terminal UIs (eg stuff that uses ncursors) to work. Moreover, the session state saving is not possible either since you need to save the internal state of running programs as well as their cached output (saving the output is really very easy but it's the least of your worries given the specifications you've described). You might also find…
Yes you can. I want to hook this up to an emulator (like qemu or MAME) with an emulated serial port. That is the PTY equivalent. I'm writing this emulator. So the emulator gets bytes from the emulated virtual machine, and then what? This needs to get fed into a terminal. While it is possible to invoke xterm with the very buggy -S option, there is no way for the emulator to suck the state back out of xterm for coheren…
You can then also forward any output to a file/terminal emulator/whatever is convenient, but relying on the terminal emulator to save part of your emulator's state seems weird to me, unless you are going to ship the two bundled together.
I wish Alacritty had better scrollback, I'd give that a go as well. But for now, I am sticking to Kitty.
Earlier quoted context omitted.
Which is a major no-no anyway, typographically speaking.
We are talking about terminals. Italics used to be drawn by skewing the pixel clock.
Earlier quoted context omitted.
Could be even faster with modern tech like HTTP2, HTTP2/PUSH, gzip, brotli and all that while looking much nicer with some basic CSS. Some additional speed could probably be squeezed out with something like anycast DNS.
I'm not sure what are you talking about. His site is served with SPDY and HTTP2 protocols https://i.imgur.com/LqGSHUj.png
1. no preferences window 2. no resize option for text 3. "Cannot find terminfo entry for 'xterm-kitty'." ie screen doesn't work in ssh makes this hardly usable
Earlier quoted context omitted.
Yes you can. I want to hook this up to an emulator (like qemu or MAME) with an emulated serial port. That is the PTY equivalent. I'm writing this emulator. So the emulator gets bytes from the emulated virtual machine, and then what? This needs to get fed into a terminal. While it is possible to invoke xterm with the very buggy -S option, there is no way for the emulator to suck the state back out of xterm for coheren…
Just capture the output from the serial port in a buffer inside the emulator, and use that to save snapshots. You can then also forward any output to a file/terminal emulator/whatever is convenient, but relying on the terminal emulator to save part of your emulator's state seems weird to me, unless you are going to ship the two bundled together.
The point of a library is that the two are more than just bundled together. They are linked together, making one executable. The terminal window is a part of the emulator.
Earlier quoted context omitted.
Theres no way you can build a terminal emulator without a PTY and still expect terminal UIs (eg stuff that uses ncursors) to work. Moreover, the session state saving is not possible either since you need to save the internal state of running programs as well as their cached output (saving the output is really very easy but it's the least of your worries given the specifications you've described). You might also find…
Yes you can. I want to hook this up to an emulator (like qemu or MAME) with an emulated serial port. That is the PTY equivalent. I'm writing this emulator. So the emulator gets bytes from the emulated virtual machine, and then what? This needs to get fed into a terminal. While it is possible to invoke xterm with the very buggy -S option, there is no way for the emulator to suck the state back out of xterm for coheren…
Earlier quoted context omitted.
Just capture the output from the serial port in a buffer inside the emulator, and use that to save snapshots. You can then also forward any output to a file/terminal emulator/whatever is convenient, but relying on the terminal emulator to save part of your emulator's state seems weird to me, unless you are going to ship the two bundled together.
Terminal state is far more than just text on the screen. For example, an escape code could change the color. After that, there could be megabytes of output created over many hours. Loading a snapshot should not require replaying all that data. The point of a library is that the two are more than just bundled together. They are linked together, making one executable. The terminal window is a part of the emulator.
The only thing that wouldn't be inlined via control characters nor escape sequences would be the PTY operating mode (which are defined via kernal syscalls). Im talking about stuff like local echo, flow control, how CR/LF characters are handled, etc. However that's solved with a multiplexer (screen or tmux type thing) or a custom shell, thus you could save that running state and reset it when needed (shells actually already need to do this to some extent so they can pass control of the TTY to forked processes. But we'd obviously need to take things a step further and store any state changes made by forked processes as well). However now we are back to my original solution you dismissed.