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

201–210 of 323 posts

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

#201

Post by JdeBP »

sime2009 wrote: post #155
beefsack wrote: post #73

Earlier quoted context omitted.

This is less of an issue if you use a multiplexer like tmux, so how appropriate Alacritty is depends on how you use it.

The big idea of Alacritty is that it uses the GPU for superfast rendering and updates. But relying on tmux for scrolling seems to be a case of "penny wise and pound foolish". Having to round trip key presses and updates through a separate and possibly remote process (tmux) just to do scrolling, introduces a bunch of latency. "Normal" emulators with built in scrolling don't have this problem. Scrolling is purely local…

It's not for scrolling, it is for scrollback.

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

#202

Post by laumars »

jstimpfle wrote: post #191
zaat wrote: post #180

Earlier quoted context omitted.

I switched from Gnome Terminal after running large duplicity backup with -v failed repeatedly, apparently because the terminal didn't held the load. Switching to urxvt256-ml solved the problem.

When the terminal is too slow, the producer is throttled. This is called flow control, which is implemented by putting the consumer to sleep when the buffer from the producer to the consumer terminal is full. No backup program should fail because the terminal is to slow.

I guess that would depend on whether the backup is reading from and/or writing to an external drive without read/write buffers (eg the early CD writers from the 90s). Having the handler program paused might cause io errors there which would legitimately cause the backup to fail.

However I do agree with your point that this "shouldn't" happen in practice (ie any decent hardware you'd expect to have buffers to prevent that kind of write errors).

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

#203

Post by aumerle »

morsch wrote: post #176
ryenus wrote: post #71

Earlier quoted context omitted.

Have you managed to configure it to behave similar to iTerm 2 in terms of keyboard shortcuts? Would you please share your config? One thing is, I don't get its layout , is it possible to create a vertical/horizontal split like what (shift+)cmd+d does in iTerm 2?

Ctrl-Shift-Enter opens a new "window" -- this is the terminology in the Kitty docs; it's a new terminal within the same frame, both being visible at the same time. Ctrl-Shift-L goes through all enabled layouts. A layout specifies how the "windows" are arranged. Simple splits are available among others. I like the stacked layout: window 1 fills the full height on the left half of the screen, all other windows are stac…

You can freely resize layouts using hte keyboard (but not the mouse) see https://sw.kovidgoyal.net/kitty/#layouts but be aware that it currently does not work in the released kitty because of a regression, so you will need to run kitty from master

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

#204

Post by jstimpfle »

laumars wrote: post #202
jstimpfle wrote: post #191

Earlier quoted context omitted.

When the terminal is too slow, the producer is throttled. This is called flow control, which is implemented by putting the consumer to sleep when the buffer from the producer to the consumer terminal is full. No backup program should fail because the terminal is to slow.

I guess that would depend on whether the backup is reading from and/or writing to an external drive without read/write buffers (eg the early CD writers from the 90s). Having the handler program paused might cause io errors there which would legitimately cause the backup to fail. However I do agree with your point that this "shouldn't" happen in practice (ie any decent hardware you'd expect to have buffers to prevent…

It is most certainly reading from a drive, or from a TCP stream. Reading from CD-ROMs shouldn't be a problem either. In other words, I doubt that the terminal was the actual problem.

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

#206

Post by boobsbr »

wiz21c wrote: post #163
boobsbr wrote: post #124

Earlier quoted context omitted.

Why do you need ligature support?

If you code in the console with this : https://github.com/tonsky/FiraCode ??? Dunno...

In this case, it's more of a 'nice to have' feature than a 'I need it' feature.

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

#207

Post by zaat »

jstimpfle wrote: post #204
laumars wrote: post #202

Earlier quoted context omitted.

I guess that would depend on whether the backup is reading from and/or writing to an external drive without read/write buffers (eg the early CD writers from the 90s). Having the handler program paused might cause io errors there which would legitimately cause the backup to fail. However I do agree with your point that this "shouldn't" happen in practice (ie any decent hardware you'd expect to have buffers to prevent…

It is most certainly reading from a drive, or from a TCP stream. Reading from CD-ROMs shouldn't be a problem either. In other words, I doubt that the terminal was the actual problem.

It reads from a drive, encrypts each file and writes it, so there is an element of a large buffer to hold.

I Wouldn't think that the terminal is the actual problem, but running the same job side by side consistently failed on the gnome terminal and finished successfully on urxvt.

On a side note, OP remark on CD-ROMs was regarding writing, CD-ROMs write feed had to be an uninterrupted, continuous stream, and the smallest hiccup would blow the operation and render the media useless.

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

#208

Post by tazard »

jstimpfle wrote: post #195
mjtribue wrote: post #192

Earlier quoted context omitted.

Could you please provide more details on the speed issues with tmux?

It's, well, slow. Haven't done any measurements, but it's noticeable. To do its work tmux must be basically another terminal emulator, and it seems it isn't the fastest at it. It's still strange, neither a little context switching (tmux is an extra process in the pipeline) nor doing the terminal things should amount to more than a millisecond. I think.

I haven't had any speed issues with tmux. Maybe you have something in your config that's slowing it down?

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

#210

Post by morsch »

aumerle wrote: post #203
morsch wrote: post #176

Earlier quoted context omitted.

Ctrl-Shift-Enter opens a new "window" -- this is the terminology in the Kitty docs; it's a new terminal within the same frame, both being visible at the same time. Ctrl-Shift-L goes through all enabled layouts. A layout specifies how the "windows" are arranged. Simple splits are available among others. I like the stacked layout: window 1 fills the full height on the left half of the screen, all other windows are stac…

You can freely resize layouts using hte keyboard (but not the mouse) see https://sw.kovidgoyal.net/kitty/#layouts but be aware that it currently does not work in the released kitty because of a regression, so you will need to run kitty from master

Thanks, that's... certainly better than nothing. Works in the 0.11.3 release that I'm running.
Post reply on HN