Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kitty – a fast, featureful, GPU based terminal emulator

sw.kovidgoyal.net

Post reply on HN
Print view View original

311–320 of 323 posts

Re: Kitty – a fast, featureful, GPU based terminal emulator

#311

Post by burfog »

laumars wrote: post #307
burfog wrote: post #305

Earlier quoted context omitted.

This whole conversation is weird, and I'm really not sure what is missing from my explanation. In case you missed it, I am an author of an emulator. I write the emulation, and my emulator supports guest software that needs terminals. The serial port is an emulated 16550 chip. It is much more than a PTY. It has clock divider registers, an interrupt cause register, a transmit holding register, etc. Scroll back buffer h…

I'm the author of several serial interfaces for 8 bit micros plus a bunch of Linux terminal solutions. If you've taken a snapshot of the server and restore that then it should resume where you left it. All the terminal emulator then needs to do is restore a scroll back session. Thus when you press backspace (or whatever) on the terminal emulator it would transmit that character to the server and the server side softw…

my reply is up a level due to a HN glitch https://news.ycombinator.com/item?id=17949814

also https://news.ycombinator.com/item?id=17949897

Re: Kitty – a fast, featureful, GPU based terminal emulator

#312

Post by ikornaselur »

kungtotte wrote: post #216
ikornaselur wrote: post #102

Earlier quoted context omitted.

That's something I really need as well - I like how fast kitty is compared to iterm2, but I'm just so used to using the splits in iterm2 + using a global keyboard shortcut to show and hide the terminal. I couldn't find anything similar in a quick glance over the config :/

For showing and hiding with a global keyword, couldn't you rely on your DE/WM to handle that for you?

Sorry, DE/WM? I assume WM is Window Manager, but can't think of what DE is, except Desktop something?

I'm using macOS and unfortunately not familiar with how I'd do that, but I'm sure it would be easy with something like i3wm on linux (which I still miss after moving away from linux 3 years ago :/), but I don't know what I could use in macOS.

Maybe I could find some third-party solution just to show/hide a particular application. I think if I had that + if I could figure out tabbing/tiling behaviour of Kitty, I would switch to it. Those two things are the main things that I need from iterm.

Re: Kitty – a fast, featureful, GPU based terminal emulator

#313

Post by laumars »

burfog wrote: post #310
laumars wrote: post #308

Earlier quoted context omitted.

With the greatest of respect, the way you casually drop technical terms out of context suggests to me that you really don't understand how terminals work in the slightest. (That and the new revelation that you're restoring your BBS snapshots in random orders yet expecting your terminal to be smart enough to guess where to resume). This is why I think we are having such a high degree of difficulty agreeing on your pro…

I have written termcap and terminfo entries, and I am a vttest contributer. I admit that I haven't yet written a terminal. I've owned a few physical ones: VT100, VT220, VT320, VT510, and some awful Televideo thing. I do restore snapshots in random orders, and I really want my terminal to know exactly where to resume. I don't expect the terminal to guess. I expect it to accept a blob of serialized state data, and of c…

Assuming all that is true, in that case you must be aware that the unusual requirements you're placing makes this completely impossible. I just don't understand how you can claim to understand how terminals work yet still expect the kind of behaviour you're expecting and making the kind of comments you've been making.

Honestly, just stick this stuff behind a terminal multiplexer and move on with your life. You're trying to over-engineer a solution to a problem you're inventing.

Re: Kitty – a fast, featureful, GPU based terminal emulator

#314

Post by laumars »

burfog wrote: post #309
laumars wrote: post #304

Earlier quoted context omitted.

There isn't anything writing to the serial port. The process of writing to the serial port is fast enough that the IO isnt the problem. What you're after is the capture of stuff that has already been outputted on the terminal and that can be captured. It's called a scroll back buffer history. Some terminals can even make that persistent. You keep trying to reinvent terminals with features that already exist to solve…

I didn't see a "reply" link below. This is a https://news.ycombinator.com/item?id=17949657 response. I emulate lots of different things. I'll make up an extra-simple case to illustrate the problem. The guest OS running in the emulator is just a bootable floppy image for testing. All it does is print a counter to the serial port, once per hour. Just after 3 hours it has written 0, 1, 2, 3. At this point I make a snaps…

> I can only avoid this fate by saving full terminal state whenever I save the emulator state, and of course restoring it at the same time too. There is no reasonable way to extract terminal state from a separate terminal program. (attacking it with ptrace is not reasonable) I thus conclude that the terminal must be built into the emulator.

It's called a "terminal multiplexer" and that is exactly what I suggested with the tmux solution right from the bloody start. I've lost track of how many times I've said this needed to be solved on the server yet you repeatedly pushed back on both points when they were made, insisting it was a terminal emulator issue on the client side.

Re: Kitty – a fast, featureful, GPU based terminal emulator

#315

Post by burfog »

laumars wrote: post #314
burfog wrote: post #309

Earlier quoted context omitted.

I didn't see a "reply" link below. This is a https://news.ycombinator.com/item?id=17949657 response. I emulate lots of different things. I'll make up an extra-simple case to illustrate the problem. The guest OS running in the emulator is just a bootable floppy image for testing. All it does is print a counter to the serial port, once per hour. Just after 3 hours it has written 0, 1, 2, 3. At this point I make a snaps…

> I can only avoid this fate by saving full terminal state whenever I save the emulator state, and of course restoring it at the same time too. There is no reasonable way to extract terminal state from a separate terminal program. (attacking it with ptrace is not reasonable) I thus conclude that the terminal must be built into the emulator. It's called a "terminal multiplexer" and that is exactly what I suggested wit…

I'm normally not a BSD user. I'm more familiar with "screen" than "tmux". To me, a "terminal multiplexer" is a physical piece of hardware. It has numerous slow serial lines to which one may attach terminals, modems, or consoles. It time-multiplexes them to/from a single high-speed link, typically by interleaving the streams of data bit by bit.

I don't see tmux being available as a library that I could link into my emulator. If it can be a library, then yes my emulator could implement the tmux protocol. This turns out to be almost exactly what I was proposing, with the terminal state implemented by a library within the emulator. I'd just be missing the user-friendly aspect of automatically popping up the terminal windows when my emulator starts, but perhaps that could be arranged by having the emulator start xterm running tmux.

This is comparable to using vnc protocol for VGA. I have this implemented, but nobody likes to use it. Everybody prefers the built-in video window to show the guest's VGA.

If you meant to not link in the tmux code though, that won't work.

Instead of insisting that there is a terminal emulator issue on the client side, I insist that there not be a distinct client. The code that tracks terminal state (cursor position, current character attributes, etc.) pretty much needs to live in the emulator. That is the only reasonable way to ensure that the state can be saved and restored by the emulator. Actually displaying this state could be done by connecting a client (annoying) or just by popping up a window.

Another nice thing about having the terminal windows built into the emulator is that they all go away when the emulator does, even if that is a crash.

Re: Kitty – a fast, featureful, GPU based terminal emulator

#316

Post by laumars »

burfog wrote: post #315
laumars wrote: post #314

Earlier quoted context omitted.

> I can only avoid this fate by saving full terminal state whenever I save the emulator state, and of course restoring it at the same time too. There is no reasonable way to extract terminal state from a separate terminal program. (attacking it with ptrace is not reasonable) I thus conclude that the terminal must be built into the emulator. It's called a "terminal multiplexer" and that is exactly what I suggested wit…

I'm normally not a BSD user. I'm more familiar with "screen" than "tmux". To me, a "terminal multiplexer" is a physical piece of hardware. It has numerous slow serial lines to which one may attach terminals, modems, or consoles. It time-multiplexes them to/from a single high-speed link, typically by interleaving the streams of data bit by bit. I don't see tmux being available as a library that I could link into my em…

To be honest I think you've decided on the worst possible way to solve your problem. But good luck with your endeavour non-the-less. :)

Re: Kitty – a fast, featureful, GPU based terminal emulator

#317

Post by rbanffy »

tambourine_man wrote: post #294
rbanffy wrote: post #277

Earlier quoted context omitted.

We are talking about terminals. Italics used to be drawn by skewing the pixel clock.

Sure but we have bitmap displays now. There’s no reason our tools can’t take advantage and adapt to the times.

True, but generating italics when they are not explicitly defined is a perfectly reasonable thing to do.

Re: Kitty – a fast, featureful, GPU based terminal emulator

#318

Post by burfog »

laumars wrote: post #316
burfog wrote: post #315

Earlier quoted context omitted.

I'm normally not a BSD user. I'm more familiar with "screen" than "tmux". To me, a "terminal multiplexer" is a physical piece of hardware. It has numerous slow serial lines to which one may attach terminals, modems, or consoles. It time-multiplexes them to/from a single high-speed link, typically by interleaving the streams of data bit by bit. I don't see tmux being available as a library that I could link into my em…

To be honest I think you've decided on the worst possible way to solve your problem. But good luck with your endeavour non-the-less. :)

I think it is unavoidable. It follows naturally from insisting on user-friendly snapshots.

It is typical for emulator authors to just give up, letting the terminal be inconsistent after loading a snapshot.

So far I've done just that... but my users love loading snapshots.

Re: Kitty – a fast, featureful, GPU based terminal emulator

#320

Post by cosmojg »

noloblo wrote: post #287

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

1. There's a configuration file, and it's incredibly well-documented. You can simply reference the default config, read the manpages, or read the available documentation for help. See:

https://sw.kovidgoyal.net/kitty

2. There is a resize option for text. Hell, in my experience, Kitty seems to have the most powerful font management of any terminal. See:

https://sw.kovidgoyal.net/kitty/conf.html#conf-kitty-fonts

3. That's because the machine you're SSHing into doesn't have Kitty's terminfo files. That's easily fixed by running "kitty +kitten ssh myserver" where "myserver" is the IP/domain of your server. See:

https://sw.kovidgoyal.net/kitty/faq.html#i-get-errors-about-...

Post reply on HN