Kitty is super fast. Very stable. Well maintained. Provide the minimal features (split screen, tabs) for a fully working terminal (no need to add another indirection layer, like tmux, that will add complexity to your workflow, or hope that your OS have a window manager that will fill the features gap left by Alacritty).

I understand the point of Alacritty, their reasons, and it is a great terminal but it seems that Kitty has all of Alacritty's strenghts plus do not lack the minimal set of features to make it a fully working terminal out-of-the-box.

I just finished working on shell integration for kitty. Before releasing, I'd like some testing/feedback from the community.

In brief, shell integration enables features such as:

• Open the output of the last command in a pager such as less (ctrl+shift+g)

• Jump to the previous/next prompt in the scrollback (ctrl+shit+z/ctrl+shift+x)

• Click with the mouse anywhere in the current command to move the cursor there

• The current working directory or the command being executed are automatically displayed in the kitty window titlebar/tab title.

• The text cursor is changed to a bar when editing commands at the shell prompt

• Glitch free window resizing even with complex prompts. Achieved by erasing the prompt on resize and allowing the shell to redraw it cleanly.

• Sophisticated completion for the kitty command in the shell

• When using confirm on quit windows that contain a shell sitting at the prompt doing nothing are optionally ignored (if you use negative numbers for confirm_on_quit)

It's currently implemented for the zsh, fish and bash shells.

It works by installing hooks into the shell that inform kitty of changes in the shell state, via escape codes allowing kitty to know various things about the shell such as the location of the prompt, the command being run, etc. kitty then uses this information to enable the above features.

What I would like is:

1. Testing, especially if you already use some kind of fancy prompt setup, does the integration work with it/break it?

2. Comments on how well the functionality works/how useful it is

Details on how it works and how to configure it are in docs/shell-integration.rst

To try it out use a nightly build of kitty

curl -L https://github.com/kovidgoyal/kitty/raw/master/docs/installer.sh | sh /dev/stdin \
    installer=nightly dest=/some/other/location

or build from source.

Running it should automatically enable shell integration if you use one of the supported shells. To turn it off simply set

shell_integration disabled

in kitty.conf

Note that shell integration for bash only will write three lines at the end of your .bashrc. These are safe to remove at any time, and will have no effect unless you are running kitty with shell integration enabled. This is needed because bash is the only shell that provides no way for the invoking program to inject code into it robustly.

Thanks, and enjoy!

I've being using kitty for quite some time and slowly questioning the need of a terminal multiplexor (tmux). One thing that I could not find in kitty, though, is the ability to run it as a daemon (server) just like tmux. So, for example, I can create a kitty session and close the UI without destroying the current session. Which means that, later, I can resume that session.

Do you have any plans on implementing this behavior?

Thanks!

More and more text editors are adopting the concept of multiple cursors, I'm playing with one of them called kakoune.

In order to draw multiple cursors consistently, kakoune has to hide the terminal cursor completely and "draw" its own cursors by manipulating background color of a cell. This is ugly hack that prevents people from using the much superior native cursor with all of its features (different shape, blinking, proper color).

In vim you only see one cursor, even if you are editing multiple lines, but there you are not editing multiple lines simultaneously anyway (vim waits for ESC to be pressed, then applies the same edit on the rest of the lines).

In kakoune, multiple lines are being edited at the same time, potentially in different positions, so it's really beneficial to show multiple cursors.

What I was thinking about is to propose you to think about multiple cursors as an extension over xterm protocol.

I asked for how this works in layman terms, I was told applications like kakoune or vim take care of handling keypresses and rendering the text on the screen, and then they tell the terminal to put a cursor in a certain place, kind of like move (x,y). What is missing is the ability to draw more cursors, e.g. like draw (x1,y2). These "secondary" cursors should basically be a copy of the main cursor in terms of color, shape and blinking. And then there should be a way to remove all "secondary" cursors from the screen.

I brought this to you because you understand a lot more about the terminals, and I want to hear your thoughts. I hope I managed to at least explain the need for this feature: multiple cursors is a thing that is becoming more and more popular and demanded by users (here's just one example in neovim), unless terminal allows drawing them, software has to completely take over drawing cursors, and of course software-rendered cursors cannot ever have the features like shapes and colors and blinking that native cursors easily provide.

urxvt has the ability to select text using just the keyboard. By hitting a key you enter into something akin to Vim's normal mode (where you can move the cursor with your keyboard and select text using v). I found this to be a great productivity boost and would be great if kitty supported it as well.

I am using the onedark colorscheme in neovim. If I set the option termguicolors then kitty borks and throws [PARSE ERROR] Invalid character in CSI: 0x3a, ignoring the sequence repeatedly.

Here is a comparison with terminator(left) and kitty.

In case I don't set termguicolors in my .vimrc, then it kinda works, but the colors are quite different (I believe the colorscheme then uses 256 colors instead of truecolor.)

Since the previous kitty keyboard reporting protocol was not well received, I have implemented a new one. The new proposal is backward compatible by default producing the exact same bytes as traditional terminals. Applications that want to enable more robust key handling can use progressive enhancement to request more sophisticated behavior. Notable features:

1. Distinguish between press, repeat and release events. And the four modifiers ctrl, shift, alt, and super.
2. Have a "game mode" where all key events generate escape codes rather than some generating text and some escape codes
3. Disambiguate all key presses. Currently, many key presses are overlapping, generate the same bytes, the most egregious example being pressing Esc.
4. Allow reporting the pressed key, the shifted key and an "alternate" key in the default keyboard layout for advanced shortcut matching
5. Allow sending text encoded as unicode code points within the escape code rather than as separate UTF-8 bytes. This is useful for applications that want to customise text+key event handling.
6. Add a way to query for support and current progressive enhancement level. Also allow saving and restoring current enhancement level on a stack.
7. Make a canonical mapping of functional key names to PUA unicode characters.
8. Support any key from any language that is present in Unicode.

The new protocol has been implemented in master and will be in the next kitty release. The spec for the protocol is: https://sw.kovidgoyal.net/kitty/keyboard-protocol.html

The new escape code is based on the proposal in http://www.leonerd.org.uk/hacks/fixterms/ however, it is more general and fixes various bugs in that proposal.

If there are bugs or things I have overlooked, now is the time to point them out. You can test the implementation in kitty (which is mostly complete, barring bugs) by building kitty from master and running

kitty +kitten key_demo

inside kitty, to see how key events are reported with full progressive enhancement.

@msokalski Please check if this meets your game use case

@gnachman I believe iTerm implements some version of fixterms, so you might be interested in the bugs I discovered in that proposal

@leonerd Please look over the list of bugs in fixterms and correct me if I am wrong about anything https://sw.kovidgoyal.net/kitty/keyboard-protocol.html#bugs-in-fixterms

In particular, there is some controversy about how to encode shift+key, for instance should ctrl+shift+a be encoded as CSI 97; 6 or CSI 65; 5 IMO the former is correct. One reports the actual key pressed, not the shifted form of the key. In my spec the shifted form is available as a sub-parameter.

A general note, I will not entertain bike-shedding about the escape code format. Unless there is a serious bug or concern that causes backward incompatibility/inoperability.

• Avoid unnecessary which and fix typos.
• Adjust the order of exec function definitions: zsh, fish, bash.
• Improve SSH detection without affecting daily performance.
• Remove the fish integration B prompt marking. (The same as zsh, bash.)

For SSH detection, first exclude the case that KITTY_PID exists. Then check the existence of KITTY_WINDOW_ID. Call who only if sudo is running (environment variables are cleared) and shell integration is manually installed for the switched user.

• When run locally, only one environment variable, KITTY_PID, will be checked.
• In most SSH connections, only KITTY_PID, SSH_TTY will be checked.
• Only when the integration is installed manually and sudo is run, four environment variables will be checked and who will be called once.

Users can add KITTY_WINDOW_ID to sudo env_keep to avoid calling who. SSH_TTY is not suitable for adding to env_keep, because it is possible that the switched user does not have permission to access it and affecting other programs.

Please review, thank you.

I'm a little concerned about whether tar x --no-same-owner will work properly on OpenBSD and am going to give it a try.

Describe the bug after commit ac407d42, the window cannot be moved after launching kitty

To Reproduce Steps to reproduce the behavior:

1. launch kitty using kitty --config NONE
2. use mouse to drag the window
3. the window simply does not move

Environment details

kitty 0.24.4 (90ed5959de) created by Kovid Goyal
Linux mendaxca 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64
Debian GNU/Linux 11 mendaxca /dev/tty

Running under: Wayland
Frozen: False
Paths:
  kitty: /tmp/kitty/linux-package/bin/kitty
  base dir: /tmp/kitty/linux-package/lib/kitty
  extensions dir: /tmp/kitty/linux-package/lib/kitty/kitty
  system shell: /bin/bash

Config options different from defaults:

Important environment variables seen by the kitty process:
	PATH                                /home/mendaxca/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
	LANG                                C.UTF-8
	VISUAL                              nvim
	SHELL                               /bin/bash
	GLFW_IM_MODULE                      ibus
	DISPLAY                             :0
	WAYLAND_DISPLAY                     wayland-0
	USER                                mendaxca
	XDG_MENU_PREFIX                     gnome-
	XDG_SESSION_DESKTOP                 gnome
	XDG_SESSION_TYPE                    wayland
	XDG_CURRENT_DESKTOP                 GNOME
	XDG_SESSION_CLASS                   user
	XDG_RUNTIME_DIR                     /run/user/1000

Thoughts on implementing support for raster graphics in kitty (and terminals more generally). Out of curiosity, I spent some time looking into the existing imaging solutions in terminals, I found:

1. https://github.com/saitoha/libsixel (seems the most advanced, but is fundamentally limited by backwards compatibility)
2. https://www.iterm2.com/documentation-images.html (pretty basic, only supports displaying image files)
3. https://git.enlightenment.org/apps/terminology.git/tree/README (seems to be file based so useless over ssh)
4. https://github.com/withoutboats/notty (seems largely similar to (2))

My question is, why are we limiting ourselves to this image file display paradigm? Why not allow programs to render arbitrary pixel data in the terminal? The way I envision this working is:

1. An escape code that allows programs running in the terminal to query the terminal for the current character cell size in pixels (this is similar to how querying for cursor position works)

2. An escape code that allows the program running in the terminal to specify arbitrary pixel data to render at the current cursor position (in a single cell, think of it as sending a "graphical character" instead of text character). The pixel data can be binary for maximum efficiency (taking care to escape the C0 control codes for maximum robustness).

With these two primitives, programs will be able to draw arbitrary graphics (including image files) in terminals. This, to me, seems like a more general, and powerful, abstraction to build rather than just the ability to send image files in a few formats.

I am considering building this into kitty, so I thought, that before I do so, it would be good get some more opinions on the subject. Maybe get a little consensus going. Note that once this is built it is easy to support displaying image files on top of it, if needed.

A specification for this protocol is here: https://github.com/kovidgoyal/kitty/blob/gr/graphics-protocol.asciidoc

Progress on implementing the specification:

• [x] Loading image data
• [x] Displaying images (any loaded image can be displayed multiple times). This is a little tricky because we want support for z-index. In particular images with negative z-index must be rendered in between the cell background and the cell foreground. This allows text to be written on top of images.
• [x] Deleteing displayed images
• [x] Scrolling the images with the text
• [x] Implementing checks to prevent DoS attacks by loading too many images
• [x] Handling window resizes/font size chages
• [x] Handling reset (I plan to just have the terminal emulator delete all images on reset)
• [x] Handling the alternate screen (The alternate screens images will be cleared when switching to it, but the main screen must preserve the images when switching to/away from it).

Hi Kovid,

I'm just coming to kitty from tmux, because tmux doesn't currently support image printing while kitty could https://sw.kovidgoyal.net/kitty/graphics-protocol/.

Very often, I have multiple similar windows under same tab, which serve for similar but not exactly same jobs. And it's important for me to know which is which. With tmux (https://stackoverflow.com/a/37602055) I usually set each of the window a unique name. And show them on the bottom like below (I named them as "python 1" and "python 2"):

But I didn't find this option in Kitty, do you think it worths to have this ?

Thanks,

Xiangpeng

• https://github.com/kovidgoyal/kitty/issues/3330
  • https://github.com/kovidgoyal/kitty/issues/3330#issuecomment-1273590741
  • https://github.com/kovidgoyal/kitty/issues/3330#issue-812568792
    • vim -> NG, nano -> OK

This commit introduces the Unicode placeholder image placement method. In particular:

• Virtual placements can be created by passing U=1 in a put command.
• Images with virtual placements can be displayed using the placeholder character U+10EEEE with diacritics indicating rows and columns.
• The image ID is indicated by the foreground color of the placeholder.
• Underline color can be optionally used to specify the placement ID.
• Unicode placeholders are used by the icat kitten when the --unicode-placeholder flag is specified.
• Also the --tmux flag was added to the icat kitten, which enables some tmux workarounds and Unicode placeholders.
• A bug was fixed, which caused incomplete image removal when it was overwritten by another image with the same ID.

This pull request is building on top of #3308 to blend colors in linear colorspace. It will improve font rendering and probably color accuracy when transparency is involved.

To avoid somewhat complex calculations in shaders it uses a lookup-table in a uniform for the color-pickers in the vertex-shaders for cells and borders, and the same data is used to provide the colors supplied to the shaders themselves. GL_FRAMEBUFFER_SRGB is then used to automate the conversion back to SRGB-space (if we manually converted back from linear at the end of each shader we would have to re-convert existing colors in every shader which would carry a performance penalty, this way we can mix-and match shaders in any order).

Some things I'm a bit uncertain about:

• Not sure if all the correct textures have been changed to SRGB, if some should remain RGB or not.
• Maybe there are some better/more efficient ways to provide the LUT-data to the GPU.
• How/if this will affect color on MacOS with different macos_colorspace. I have not yet tested this.

Based on #2125. The default sound theme is __custom, which is the custom theme created by GNOME and Budgie. If this theme doesn't exist, canberra instead uses the default theme to produce the sound, so it should work without a hitch on all desktop environments.

This is a draft because I was unable to figure out how to regenerate to-c-generated.h to get the changes to propagate, and it seems that the code to add a new option changed in the time between #2125 and now. Let me know how to get everything connected and I'll get it ready to merge.

Describe the bug Emoji joined via a ZWJ display properly, but the cursor is moved too far. An example:

[schwarzgerat](0) $ printf '\e[6n\U0001f9d1\u200d\U0001f33e\e[6n'
🧑‍🌾  [schwarzgerat](0) $ 1R5R

as you can see, the cursor report indicates that we have moved four -- which is accurate, as we have indeed moved four cursor positions forward. we only ought have moved two.

FWIW, it's nice that kitty actually implements this; it's ahead of most terminals in this regard.

To Reproduce Steps to reproduce the behavior:

1. Get a cursor report
2. Print an emoji created via ZWJ (there might be some that work; the example above does not)
3. Get a cursor report
4. Look and see that spaces have been printed where no spaces were desired

Screenshots

Environment details

kitty 0.21.2 (e07ba2c53d) created by Kovid Goyal
Linux schwarzgerat 5.12.14nlb #1 SMP Sun Jul 4 17:05:42 EDT 2021 x86_64
Debian GNU/Linux 11 \n \l
Running under:X11
Loaded config files:
  /etc/xdg/kitty/kitty.conf
  /home/dank/.config/kitty/kitty.conf

Config options different from defaults:
background_opacity    0.7
enable_audio_bell     False
font_family           Hack
initial_window_height (72, 'cells')
initial_window_width  (132, 'cells')
scrollback_lines      20000
update_check_interval 0.0

This debug output has been copied to the clipboard

Additional context Happens the same way.