And then people were like, well, this doesn't work in tmux, and
it doesn't work in WeChat, and it doesn't work in vim.
And I'm like, what the hell?
And then my next windmill that I'm looking at is variable-sized
text in the terminal.
So when I'm catting a markdown file, I want to see the headings big and.
Like in emacs, right? Yes, yes.
So why should only emacs user benefit.
Like Rio, for example, is a new terminal out there.
So it can adopt the kitty graphics protocol and use it, right? Yes, absolutely.
I encourage everyone to adopt it.
There's an open spec.
It's using kitty to replace the file open dialogs in Linux.
You say file, save page as.
Here you see there's actually a kitty instance that's running
a file choosing kitten.
Because ebook readers are a big boom for elderly people because
you can make the font size bigger.
In fact, I do that myself.
I don't know if you can see this on the screen.
Yeah, as I age, my eyes have gotten weaker.
And so I don't like to wear specs when reading on my Kindle.
So I make the font size big.
Do you ever get in trouble with kitty because of the language
that you decided to use Python?
Since we hear every, you know, nowadays everyone is like, rust,
rust, rust, you just hear that everywhere, right?
Um, I have a tough one for you.
I have a good question.
You want to see, let me grab your water first. Yep. Yep.
So you mentioned that we briefly talked about it.
I think you know what I'm going to ask probably, right?
So what are your thoughts on tmux?
Oh, I, do you talk to the tmux maintainer for compatibility?
When you try to deploy something new, do you have communication?
What's his name?
Um, I don't remember his name.
Um, I did try, but he wasn't interested.
So I don't anymore.
Your main IDE, which one is it?
It's, uh, it used to be vim.
Now it's, now it's neovim.
So you can see this is a kitty file inside neovim.
If you're listening to this as a podcast, remember that it was
originally recorded as a video.
If you're not following along, you can go to my YouTube channel.
My username is Linkarzu.
And if you want to support me to keep this podcast going, you
can donate in Ko-fi.
I'm going to leave a link in the description. All right.
So let's get started with this chapter then.
I have a special guest today, Kovid, which we all know is the
creator of the Kitty Terminal.
And I didn't know that you're, you're also the creator of another
application called Calibre, right?
Yes, in fact, Calibre is my main job.
Kitty is my hobby. Oh, okay.
So Calibre is the main one.
So really appreciate you being here, Kovid.
Really, really, you know, big fan of Kitty.
So thank you very much for joining us and talking about your tools today.
How's it going, by the way?
It's very good.
Thank you for having me.
I'm looking forward to a fun chat.
So what do you want to start with?
How did it all get started?
That's the first thing I want to know, because I thought, you
know, that Kitty was the main thing.
And I was like, okay, Kitty.
And I went into your profile, to your website, and then I saw Calibre.
And I was like, Calibre.
I have seen that somewhere.
It's something related to books, right?
So I'll tell you the history.
So I'm a big, personally, I'm a big reader of books.
So I read like a hundred books a year.
And I've been doing that all my life.
So at some point, I was a grad student in the US at Caltech.
And there, in the neighborhood, there were no good libraries with fiction books.
And I was too poor to buy my own books at the time.
But what I did have was a real MyTech Neo GPS navigation device.
And so I used to get books from the internet, various places,
convert them to text files, and read them on that device.
So that was my first experience with e-books.
So then, around 2006, I was still at Caltech, still a grad student,
still a lot of time on my hands.
And Sony released the first e-ink-based reader in the US.
It was a PRS-500.
So immediately, the day after it was released, I went and bought
it, and I brought it home with me.
And so I tried to use it.
Unfortunately, Sony had a proprietary USB protocol.
It didn't, it did.
But nowadays, all readers connect either using the NTP protocol
or the USB mouse-to-mouse device protocol.
Just standardized, and there were tools to interact, libraries
to interact with, and so on.
But at that time, Sony had its own proprietary USB protocol.
And so I couldn't get the device to connect to my linux computer.
I had to use Sony's proprietary software.
I mean, I don't remember now, but I think I got it either on the
VM or on a Windows computer or something.
But anyway, so I decided that, let me, since I know how to program,
and I have some spare time, let me try to reverse-engineer it
and get something working.
So I found this website called mobileread.com, which I'm still
a member of.
There were a lot of people there, hanging out who were interested
in the books to read.
And so with the help of some people there, I remember, in particular,
one guy from Russia named Igor, I ended up sort of reverse-engineering
the USB protocol.
So I used a tool to dump the actual package that the device would
send in response to commands when using the Sony software.
But I printed these out on paper, I mean, on U.S. letter sheets
of paper, since I was in the U.S.
And I would take them with me to lunch, and lunch was kind of
a complete time for me.
So I would just sit and eat my lunch and put all those cases of
USB packets and try to reverse-engineer things.
So anyway, I managed to reverse-engineer things with a lot of
help, and I released a software, something called libprs500, a
classic open source name.
And so anyway, a lot of people were very happy to have that thing
and got a bit of popularity.
So I decided to write a GUI for it, just to, you know, front-end
and add the ability.
So Sony also, apart from the proprietary USB protocol, they also
had their own e-book format called LRF, which was again proprietary
and not documented and blah, blah, blah.
So again, with the help of some people who had written some Python
code to convert to parse the LRF format and convert to this one,
I adapted that code and improved it and integrated it into libprs500
and added a basic GUI just so you can connect your device and
click on buttons to send books to it.
It's that kind of thing.
So that was the start of what eventually became Calibre.
So for a couple of years, I just kept doing that.
I would do these things every few days.
I'd fix new things, find new bugs, whatever, get all enthusiastic users.
So at some point I decided, okay, let me put out a donate button
for this thing.
Maybe I'll get a pizza, I'll be good.
So I put out a donate button on the download page for libprs500.
I think it used to run on something called Track at the time,
which was a tippeting system.
So I'm on the front page of that.
So then I started getting a lot more money than I expected.
People were supporting me.
I was surprised.
And so then around 2008, which is when I got married, I also decided
to change the name of libprs500 to Calibre and spruce it up a
bit and release it, make it available for Windows and Mac OS as well.
And sort of, you know, well, spend a little more time than I thought I did.
And so I did that.
And then I graduated a couple of years after that, I think.
Maybe a year after that, I don't remember exactly now.
And so after graduating, I was supposed to go for a postdoc.
But then my wife and I were both theoretical physics PhDs.
And so one of the things, one of the things, one of the problems
with that is that it's very difficult to get a job at the same
place as a postdoc.
Very rarely opportunities open up in the same place at the same time.
So, you know, we wanted to stay together, obviously.
We'd already been apart for, like, several years as gas students.
And so we wanted to stay together.
So I said, let me take a sabbatical from physics after graduating
from Caltech and spend a year or two working on Calibre full-time
and see how it goes.
And, you know, I'll move to wherever she's going.
Just stay with her and work on Calibre from home.
So that's what I did.
It was actually quite a, you know, hard process was I had to apply
for a visa that allowed me to do work while being a dependent.
Those were some pretty tough months.
But anyway, so it all worked out and I got my visa and I spent
a year or two working on Calibre full-time.
And that was around the time Amazon came out with this Kindle
and the e-book market where we took off.
So if you look at our history of activity in Calibre, you see
around 2010, 2011 is kind of the peak amount of activity.
And so those were the years when Calibre was really growing.
And now it's grown to, you know, has about 3 million users and
it's using over 200 contributors
It does everything you would ever want to do with an e-book.
Read it, convert it, edit it.
You can basically do whatever you want with it.
In fact, you can send it to 50 different devices.
There's a content server that allows you to browse your e-book
collection over the net and so on.
It's got an insane number of features.
So anyway, so that was how Calibre started.
And then coming to Kitty about 9 or 10 years ago, I think, I was
dissatisfied with the speed of gvim.
So I was using gvim as my editor at the time.
And I was dissatisfied with its speed.
I don't remember exactly what the issue was, but I was dissatisfied
with the speed.
I wanted to make it faster.
And so then I thought, let me try Terminal again.
Terminal is supposed to be low overhead, not loaded, blah, blah, blah.
At the time, I didn't know much about Terminals.
So when I tried that, it didn't make much of a difference in the speed.
And so then I started... benchmarking Terminals, and I found that
there were, at the time, at least the leading Terminals were all pretty slow.
So I said, you know, I can possibly do better.
And it'll be a fun side project.
That's how I started kitty.
So, you know, Calibre was mostly written in Python.
It's actually got three or four different languages, but mostly in Python.
So I started kitty in Python with the idea that I will make the
front end and, you know, use a scriptable path in Python and backend
would be in C. And OpenGL.
And so that's what I did.
I made it GPU accelerated.
Actually, to start with, my first attempt was using Qt, which
is the toolkit that I submitted from Calibre to do the actual
rendering of the text on the screen.
But that was just performance.
I could not get it to a satisfactory level.
So I decided to learn OpenGL, and at the time, I knew nothing
about GPU programming at all.
So I taught myself OpenGL and a little bit enough to, you know,
just about fit.
characters on the screen.
And then that's how kitty was born.
And I really, at that time, you know, it became popular.
And, and then, and so then, so one of, so when I, so then I made
the switch to terminal, terminal vim Sorry, that time it was vim
Not, I don't know if I said neovim, but at the time I was using
vim So I made the switch to terminal vim and there was one big problem.
There were no colored underlines.
At the time there was, yeah, there were no colored underlines.
There were no undercurls, nothing.
And I'd gotten used to that in gvim or whatever.
And so I said, okay, let me, let me, let me come up with a protocol
for this and, you know, make it happen in kitty.
And it's a little bit of a blockade and it'll become, it'll become,
I don't know.
So I'll give them here someday, implement it and I'll have, I'll
have colored underlines in my editor.
So that's what I did.
I made a protocol for colored and styled underlines in kitty and
I released it and eventually it became popular.
And today you have colored underline in your terminal thanks to
me, which is the one thing I did what to credit for.
So that was, so, so, so that was my start at, at sort of trying
to extend the terminal capabilities because, you know, as I use
the terminal more and more, I sort of found limitations.
So one of the things that I used to do was run some numerics and,
you know, I'd like to, I'd like to visualize the results.
And I should run it, I should SSH into a server and run them.
And it was painful to visualize the results.
You know, you had to populate a file, a CP to file to your local
computer and open it with the same module as SSHFS or whatever,
some sort of, you know, hacky way.
So I said, okay, let me, let me, let me make a graphics protocol
for the terminal.
So I can just, you know, cat a simple PNG image and just view it conveniently.
So that was the start.
But then once I, so once I started investigating the, you know,
existing landscape was around and I found something called sixel,
which is an ancient protocol for, for images that's existed from
the seventies or eighties or whatever.
So, but then I had various limitations.
It didn't support 24 bit color.
It's, you know, the pictures were fuzzy and the library that,
that, that existed for working with sixel was not in good shape.
So I said, okay, let me, you know, let me come up with my own
protocol that works a lot, that gets past these limitations.
And that's how the Kitty graphics protocol was born.
And, you know, I, and then in designing that, I got a lot of feedback
from people and we had a lot of discussions and stuff.
And, you know, so some, some certain goals came out of that.
So one of the, one of them was that in the local case, when we
were not accessing to a different computer and viewing an image,
you don't want to send it over the terminal because you have to
import it as text, base 64 encoded or whatever.
And that's, that kills performance.
So I added the ability to, you know, view local files and in shared memory.
So, you know, and then later on people asked for the ability to
have animated images.
It's like fine.
I've done all this, like an animation, animated images.
And then people were like, well, this doesn't work in tmux and
it doesn't work in WeChat and it doesn't work in Vim.
And I'm like, what the hell?
So then somebody, somebody came up with the idea of using a so-called,
you know, Unicode placeholder.
So, which is basically you, you know, when you want, when you
want to display an image in the terminal, you send a special Unicode character.
So it's like hex code zero, but it isn't this one special Unicode
character, private use area, which is not assigned for any other purpose.
And so that acts as a placeholder.
So an application that's not aware of the graphics protocol, just
treats that placeholder as normal text.
And then you use combining marks, a lot of diacritics and so on
to add things like the image ID and, you know, the size and the
placement and so on.
That kind of information is encoded into the text.
But because it looks at just plain normal text to the application,
like Vim or tmux or whatever, the application just, you know,
keeps it together and moves it around itself.
And even though it doesn't know that it's actually working with an image.
So with this kind of hack, you know, you could get the graphics
protocol to work with things like tmux or Vim or whatever that
didn't support the actual protocol.
So that was the next big thing I did in kitty.
And then after that, I used to get a lot of bug reports about,
you know, this key combination is not working and that key combination
is not working.
And why can't I use control-shift-d in my application to, you know, whatever.
So then I started looking into the state of keyboard handling
in terminal and it was an absolute disaster.
So, you know, I mean, words fail me.
You know, like pressing alphabetic keys would just send the keys
as those characters, you press A, it transmits the character A.
So there's no way to tell, for example, if, you know, it's a key
down event or a key up event or the A stands for a paste.
So there's something called bracketed paste in, you know, terminal
land, which was invented to solve this problem.
There's a whole bunch of problems with this.
The encoding for modifiers was so primitive that you could only
really support control and alt that were not even together.
And a lot of keys encoded to the same bytes.
So like, for example, the classic example is a tab key and the
control I key import to the same bytes.
So you can't distinguish them in terminal programs, but they should
put them before the kitty keyboard protocol.
So I ended up making the kitty keyboard protocol.
And I remember having long discussions with Bram, this was before
he passed away, about getting it into Vim.
And he ha d a lot of solid opinions about it.
But finally, eventually, he agreed and made it into Vim and made
it into neovim and various other terminals.
And today it's fairly widely used, there are several terminals
that use it and so on.
So that was the next big thing I did in kitty.
And then after that, my next windmill that I'm looking at is variable
size text in the terminal.
So when I'm catting a markdown file, I want to see the headings big and...
Like in Emacs, right? Yes, yes.
So why should only Emacs user benefit.
I want all terminal users to be able to...
Hear bigger headings, yeah. Yeah, yeah.
So there's actually a program called PresentTerm, which can make
presentations in the terminal.
So that actually uses the kitty facility for showing multiple size
text for headings and for superscripts and subscripts and so on.
But anyway, that's getting ahead of the story.
So I decided to look into that.
So there's an existing standard, as always.
I don't remember the name anymore.
But basically what it would do is you can designate a line in
the terminal buffer as twice, as two times the height, two times
the font size.
But the problem with this is that it does it for the whole line.
It doesn't do it for just one character or two characters.
So the problem with that is it doesn't work, for example, with
a multiplexer like tmux.
Because the whole line becomes double-sized when Tmux is splitting
the screen into different screens.
So we want to stop that double-sized thing at this point where
multiplex is splitting the screen.
So this was a non-starter.
I mean, a lot of people use multiplexes, so it's not going to
be suitable for this use case.
And plus, then I also wanted superscripts and subscripts.
Being an ambitious guy, I said, why stop at headings?
Let's do superscripts and subscripts as well.
So I said, okay, I've already made all these protocols, and people
keep yelling at me for it.
So let me add one more into it.
So I made what's called the text-sizing protocol.
So that protocol has the ability to make individual characters
either bigger or smaller.
So because of the nature of the terminal, it's a character, but
it's made of equal-sized cells.
So it's not completely free font size.
It has to be either double or triple or quadruple or some fraction
of a cell.
It's not fully free size, but it's a lot better than what we had before.
And then in the course of doing this work, because no good deed
goes unpunished, I also decided to look into the...
So a terminal UI is basically text.
A program like Wave Modeling Editor draws its UI using text.
There are some really cool symbols, some normal text, and so on.
So now the problem is that the program running in the terminal
and the terminal itself have to agree on the width of that text.
By that, I mean how many cells a particular piece of text takes.
So it's obvious for, let's say, ASCII text, English text, an A
takes one cell.
Emoji takes two cells.
These things are well-established.
Everybody agrees on them. So on.
But the problem is that there's a lot more to text than just ASCII and emojis.
There's thousands of languages, scripts, and there's all of Unicode.
And so when you get into that, there are all sorts of complications.
So for example, there's a pair of special characters called the
variation selectors in the Unicode standard.
So if you follow certain characters with a VS-16 variation selector,
they become wide.
If you follow a wide character with a VS-15 variation selector,
they become narrow.
Now if you think about it, if you think of the case of a wide
character becoming narrow, now a terminal is a serial device,
it gets bytes at a time, a character at a time.
So imagine the terminal emulator gets a wide character, and the
cursor has only one cell left at the current position.
So it will go to the next line and put the wide character there.
But then sometime later, you don't know how long, it could be
any amount of time, because of network delays or whatever, you get
the variation selector, which makes the wide character narrow.
But now it's on the next line.
You can't move it back up because the whole scroll back would
have scrolled, you don't know what's happened and it's not possible
to move it back up.
So now what that means is that it's impossible to measure the
width of a string of text in the presence of these variation selectors
because you need to know the screen width.
So if your wide character and the variation selector make it narrow
right at the end of the screen, then they fall off the screen
with the next line.
So you can't calculate the width anymore without knowing the width
of the string you're entering the text to.
And this is a big problem for...
If you're writing a terminal program, it becomes really difficult
to work around this and deal with other issues.
I mean, there is a whole small dashboard of issues.
I'm not going to go into them.
This was just an easy-to-illustrate one.
So anyway, to fix this, I have made yet another standard.
I've codified all the rules by which the width should be calculated.
I've specified the algorithm.
I've done all that.
And as part of the text sizing protocol, there's a subsection
of it called the width.
So now terminal programs can send pieces of text to a terminal
and specify what width they want to render in.
So it doesn't matter now if the terminal and the program don't
have to agree on the width.
If one is different from the other, it doesn't matter.
The program is in control and the terminal will just do what the
program tells it to do.
So this comprehensively solves this issue.
But I mean, this is very new.
I think this is just a few months old.
So we'll see what sort of an option it gets in the future.
But yeah, that's the latest thing I've been taking advantage of in kitty. Mm-hmm.
Now, you talked about the kitty graphics protocol.
Is that a standard now?
Is that something that all of the terminals use?
Not all by any chance, by any means.
So the modern ones tend to support it.
The older ones don't.
So, for example, I think the first terminal other than kitty that
supported it was wezterm.
And now the new kid on the block, ghostty, also supports it.
konsole supports it partly.
But then there are big holdouts.
For example, VTE library, which is used by the main terminal and
all similar terminals.
They don't support any image protocol.
I think there's some discussion about them supporting sixel.
But at the moment, they don't support anything.
So those are just standard images.
Then similarly, the multiplexers.
I think tmux supports sixel
There's a compile-time option, but not on by default.
So it's a mess.
I mean, if you're somebody whos writing terminal programming and
wants to work in a lot of terminals, you really have to work hard
and make some sort of abstraction layer over the latest protocols.
I mean, the kitty graphics protocol is by far the best.
I'm saying that, obviously, I'm biased.
But it's clear to anyone who reads the protocols that it's by
far the best design and most capable.
So anyway, I'm hoping that it's an option we'll go over time.
All I can do is wait it to go down.
Yeah, I have played a little bit with images in terminals.
And always the kitty graphics protocol seems the best option.
And I use tmux and I view images inside NeoVim.
So kitty graphics protocol is the only one that has allowed me to
do that in wezterm, ghostty, kitty, of course, as well.
So if other terminals want to adopt it, they can.
Like Rio, for example, is a new terminal out there.
So it can adopt the kitty graphics protocol and use it, right? Yes, absolutely.
I encourage everyone to adopt it.
There's an open spec.
A lot of people have asked me questions about the protocol.
And I try to answer them as quickly as possible.
And I'm happy to consider amendments to the protocol to make it
more functional or easier to implement.
Or if you go to the graphics protocol page on the kitty website,
you'll see a lot of version added things.
All changes to the protocol I've made over time in response to
requests from users and so on.
In fact, now you can even watch videos in your terminals.
MPV has a kitty backend.
And it actually works quite well.
I sometimes find myself watching videos in kitty. Interesting.
So video was not a use case I envisioned when I made the protocol.
But because of the shared memory method of transmitting images,
the performance is actually acceptable for reasonably sized videos.
And you're going to watch them inside your terminal. Okay, awesome.
Talking about out-of-the-box use cases, there's actually a full
Chromium instance that runs inside kitty using bus protocol.
The project is called AWRIT.
I guess it's a sort of play-on-all-right or something like that.
But it runs a full Chromium instance and renders it inside kitty
using the graphics protocol.
And it uses the kitty keyboard protocol for commanding the keyboard
and so on.
So you can actually have a full browser in your terminal.
Oh, I didn't know that. Interesting.
So full browser in kitty, right?
In kitty, yes.
I think it also might work in ghostty.
But ghostty's graphics protocol performance is not on par with kitty.
So I think it would be a bit slow there.
They're aware of it.
But that's sort of the out-of-the-box uses.
There's actually a page on the kitty website called integrations
with other tools.
Can I share your screen? Yeah, sure.
I'll show you the page.
I'll share it here.
So you can see it starts out with image and document viewer.
So there's a whole bunch of document viewers, PDFs.
I told you about Markdown.
And then there are these file managers.
I think Ranger was the first terminal file manager we produced.
Powered by kitty's graphics protocol.
There's a whole bunch of others.
But presentterm was the project I was telling you about.
It shows Markdown-based slides with images.
And actually now variable text size as well.
So there's a whole bunch of these, awrit
This is the full Chromium-based web browser running in the terminal.
Even the old w3m, which is a venerable project.
It's a text-mode browser, but it can show images using the kitty graphics protocol.
MPV is the video player that can play videos in the terminal.
Of course, there are all these various system data visualization tools.
There are various editors that use kitty's remote control feature,
which is the ability to control kitty over a socket using any program.
There's a whole protocol for that.
So many of these editors integrate with that remote control protocol.
So we can navigate between terminal pins, and the pins in the windows
and the editor itself seamlessly.
For example, I think you mentioned using the images in nvim.
So there are various image-filled plugins for nvim.
So this is something that I'm working on currently, in the last
month or so.
A little while back, I released something called the Panel Kitten.
Well, not a little while back.
This was quite a while back.
Initially, it used to work only on X11.
What it does is it allows you to draw panels on your desktop.
If you see on my screen, the top bar, this is actually a kitty instance
running a terminal program that shows the system information.
So the Panel Kitten...
So kitty is like your Emacs.
You run everything inside kitty? Yes.
I like to live in the terminal as much as possible. Yeah.
So let's see.
So this is something I just released called the Quick Access Kitten.
So this uses the Panel Kitten, and it gives you a terminal you
can access at a single press, and it works in macOS, in
Wayland, and in X11
It was a huge headache getting it working in all three, but eventually it managed.
So you can see here in the screenshot, the desktop background
is a program called btop, and that's running inside kitty.
And then on top of that, there is a Quick Access Kitty, which
is this normal terminal, but it's overlayed on top of the desktop.
If there were any windows open, then it would have been overlayed
on top of the windows.
So this works in MacOS, and here's a screenshot of it in hyprland and Linux.
So this is something that I've been using, working on currently,
and the part of it that I'm working on currently is using Kitty
to replace the File Open Dialogs in Linux.
So when you use a GUI program like, say, Firefox, and you say
File, Save Page As, you get a File Open Dialog, usually.
Here you see there's actually a Kitty instance that's running
a file choosing kitten.
So you can use a fuzzy finder like Selector, so you can just type a file.
You can just type a few letters and it matches files accordingly,
and you can use that to actually select files.
So because I use Calibre a fair bit, I find myself using the File
Open Dialog a fair bit, and that annoys me.
Yeah, me too.
It puts you in a completely different directory and I have to
see, okay, where am I at and go and search?
I don't like it. Yeah, exactly.
So I decided to do something about that and make one that works
the way I want it to work and uses, you know, let's keyboard-centric
and fast and developer-friendly, blah, blah, So that's what I'm
currently working on in Kitty.
So the preview I showed you just now, it's not very good
and could be worked on.
But yeah, that's what I'm working on these days. Okay.
Now, for people that don't know about Calibre, would you mind
sharing a little bit about Calibre with us?
Just letting us know what Calibre is for people that just know Kitty, right?
Just a quick overview.
So Calibre is an e-book management program.
So e-books are basically electronic books.
So what Calibre does is it allows you to manage a collection of e-books.
So Calibre is mainly meant for somebody who's really into books,
who wants to manage their own collection.
If all you do is read one book a year, there's no need for Calibre.
But if you're a serious reader, you read a lot of books, you have
a collection, you'd like to search it, etc., then Calibre is for you.
So its main interface is just a collection of books.
You can change it to show covers, if you prefer that, and so on.
Like Kitty, it's very much a swiss army knife, that's my philosophy in software.
So it has a ton of features.
You can edit the metadata of books, you can change the title,
you can change the author, series, rating, whatever.
You can download metadata.
So there's a plug-in system which allows you, Calibre, to go and
download metadata from different websites, amazon and a whole bunch of other programs.
So that's the edit metadata.
You can convert the books to different formats.
So sadly, there's no standardization in the ebook space.
EPUB is supposedly the standard format, but Amazon has its own
proprietary format, and then Kobo, which is another ebook-reading
device, has its own format called KEPUB.
So as you can see, Calibre allows you to convert to all these
various formats, including a bunch of legacy formats, like LIT,
which is an ancient ebook format that Microsoft introduced.
LRF was the ebook format, Sony's proprietary ebook format, and so on.
You can even convert to Word documents, if you like, to and from, actually.
So there's that, there's Convert, and there's View, there's Calibre's
built-in Viewer, so you can view books.
This is in dark mode, so it's white on black, but normally it's
black on white.
So you can view books, and the Viewer is actually capable of text-to-speech,
and it has a pretty sophisticated search function, so you can
search by text, you can search for whole words, nearby words,
content, blah, blah, blah.
So it's a good, it supports highlighting, you can highlight things.
Add notes, and all that stuff.
Add notes, highlight stuff, all that stuff, it's got everything
that you would possibly want to do.
And as with all my software, it's extremely customizable, it's
got a huge set of preferences
So it even has like a built-in Kindle app, we could say, right?
So you can read, annotate, do everything with your books there.
Yes, and not only, so I've shown you this, I've shown you this
running, you know, a software on your desktop, but Calibre also
has something called a Content Server, so you can start the Content Server,
so start Content Server, and then if you go to the, I actually
don't know how this is currently set up, but you can access your
libraries in a browser.
So this is a browser, this is actually Vise, which is my own personal
browser, but you can access it in any standard browser.
So you can access a collection on a browser, you can read the
books, the same book that I was reading in the Calibre viewer,
you can read it in your browser.
So you can change pages, blah, blah, blah, whatever.
And this works on mobile phones devices as well.
So if you expose it correctly, you could access it from any device
in your local network?
Any device in your local network, or even over the internet, if
you want to, it supports authentication and so on.
So you can expose it over the internet, and when you're traveling,
you can read books.
That's up to you what you want to do with it.
Quick question, quick question before you move on.
Is there a Docker container version of Calibre
that I can host on a server?
There probably is.
There is actually, but I personally, so Calibre comes as its own
self-contained binary, but not a single binary, but a tar file
which you untar into one directory.
All you need to do is untar that tar file, and then you can run
the server without it.
It's all its dependencies bundled, you don't actually need tar.
So you can go to
So I can run it in a headless server, no GUI?
Yes, no GUI, just run the server.
There's an executable called calibre-server, so you can run the
server, and that same server is running now via command line program
So you can install this on any Linux machine and run the server
and access it from anywhere.
In fact, there are other projects, third-party projects that make
their own Calibre servers, the most popular is something called
Calibreweb, so you can use that instead with your Calibre library
if you don't like the look of the default.
So one other feature I'd like to highlight in Calibre, which some
people don't know about, is the Fetch News feature.
So the Fetch News feature basically allows you to download news
from news websites, publicly accessible websites.
So you can see that there's a whole bunch of, there are thousands of these.
These are based on scripts called recipes that are maintained
by Calibre users and me.
And so they go out and they scrape the website and they download
the news, and you can read the news as an e-book.
So this is nice because it gives you a distraction-free sort of
environment in which to read the news.
You can't comment and you can't get distracted by external links
and so on.
And you can just focus on the actual content.
So I do that.
I mean, I personally, like I said, I read a lot.
So I download three or four of these publications every week and
I read them.
In fact, one of my happy side effects is my daughter also uses
Calibre to download publications and she likes to read them and
I read them.
So that was something kind of cool to see for myself.
So yeah, that's the main headline features of Calibre.
But it's, of course, it's the tip of the iceberg and I think that's suitable for.
Now, my wife has a Kindle and sending books to that thing is not
something that I enjoy, you know, because I have to send it to
an email or I have to download an app.
And it's just, I keep forgetting how to send books to it.
If I have to send a book right now, I don't know how to do it.
I don't remember.
I have no idea.
So let me give you a demo.
I have a Kindle somewhere here.
Let me just pick it up.
I think this is the Kindle paper.
I can see it.
Yeah, I see it.
So all I need to do is good old USB cable.
There's no network.
Amazon is not snooping on me.
My Kindle stays in airplane mode all the time.
I plug it into the, I'm plugging it into my laptop.
If you look at the screen, if you look at the screen, yeah, it'll
show up in a minute.
It takes just two seconds to connect.
You see, it's connected.
So you just, so you just click on the book.
Say I want to read the importance of being honest.
You just click on this book and then click send to device.
And Calibre will ask you convert the book to the format for the device.
Because it's not pre-converted.
Click yes, and that's it.
It will automatically convert it to whatever Amazon's format is.
Mobi, I think.
Yes, yes, yes, yes.
Mobi is the old one.
Amazon actually has three formats.
Let's not get into that.
But it will get the most appropriate format for your Kindle
and put it on the Kindle automatically, you can see the list of
books on the device.
You can, you know, delete them, whatever.
transfer into your library and so on.
So it's very simple, as you saw, you know, just plug it in, click
the book and you click a button.
And in fact, one of my happy, happy things I'm happy about with
Calibre is I get a lot of positive feedback from elderly people.
And because ebook readers are a big boom for elderly people, you
can make the font size bigger.
In fact, I do that myself.
I don't know if you can see it.
But yeah, as I age, my eyes have gotten weaker.
And so I don't like to wear specs while reading on my Kindle.
So I make the font size bigger.
So, uh, you know, when I started, I didn't need that.
Now I do.
So, so, so I, but the point is, I get feedback from
a lot of non-technical people, people who are, uh, you know, not
so comfortable with computers saying that they really find Calibre
easy to use.
And now they're, they're able to use it.
And a lot of people, you know, introduce their parents to it.
And they're self-sufficient and they can figure it out on their own. Yeah.
So that's really a good feeling.
If you can figure it out. Yeah.
It has happened to me as well.
My font size used to be smaller.
It increased this last year.
My resolution also increased.
So it's just going to get bigger and bigger from now on.
I have a question for you.
Have you gotten in trouble with Sony or with Amazon or any of
these companies due to this tool?
No, not at all.
I don't, uh, so Calibre itself doesn't have any, uh, say DRM breaking facilities.
Although there are third-party plugins that do this, Calibre itself
doesn't do anything.
So I've never gotten in trouble.
In fact, in fact, in the early days, Sony wanted to buy Calibre.
I remember going to their San Diego offices and talking to them about it.
I don't know.
One thing that didn't end up happening, but yeah, no, I've never
gotten in trouble.
Did they, didn't they get upset when you reverse engineered their
protocol and all that stuff, Sony?
They were really happy.
So, you know, Calibre ended up being a better program than their
proprietary reading program.
Which often happens, you know, when the hardware companies are
not good enough to make software or whatever.
So, uh, and so they were happy because, uh, you know, Calibre
was making their device more useful using their sales.
They had no problem with it.
Um, and in fact, so the PRS-500, the first one that at least had
their own proprietary protocol, but later on they changed and
the later models use the standard USB mass storage protocol.
And so, uh, you know, there was no need for reverse engineering,
uh, their protocol.
And they started supporting the pod format over the next years
that the PRS has gone through.
So, so that was, uh, you know, good thing.
And yes, they never had any, any, any issues with Calibre.
Same with Amazon.
I've had only, I think one interaction
with somebody at Amazon, which was about some technical issue,
but no, no, no, no problems. Okay.
Now, um, well, Rumen in the comments says that, genius, that is
what happens when a software developer solves problems for something
that they're using.
You use your tools, right?
That's like one of the, yeah.
So I mean, I make them because I use them myself. Yeah.
That's the reason I mean, that's the reason they're, they're good actually.
Now, do you ever get in trouble with Kitty because of the language
that you decided to use Python?
Since we hear every, you know, nowadays everyone is like Rust, Rust, Rust.
You just hear that everywhere. Right?
Uh, so on the contrary, I think Python using Python is one of Kitty's strengths.
Um, so Kitty has a system called Kittens, which are like small
programs that you can use to, uh, you know, to customize it behavior
and modify its UI and so on.
And so these are in Python and, and this feature was easy for
me to add because Kitty was already in Python.
Uh, so, you know, the problem that most people have with Python
is that it's slow, but that's irrelevant because you will drop
down to C or some other compiled language, whatever you like,
um, for the performance sensitive parts.
So like, for example, uh, in, in Kitty, um, the parsing of the
text stream from the terminal program actually, uh, uses, uh, SIMD instruction.
So that's, that's the one, um, in multi, uh, processing, uh, multiple
amounts of data with a single CPU instruction, uh, so-called vector programming.
Um, so I had to, so I wrote that by hand, uh, using a library
called SIMD in C.
And so, so, you know, when Kitty's parsing data, which is the
performance sensitive part, it does this using, not even using,
you know, regular C, but using something called SIMD, which is,
which leverages your processor to the maximum for maximum performance
and power efficiency.
So, you know, the Python is not involved at all.
Like once all the parsing is done and most of the, you know, things
be converted to characters and styles and whatever else, then
at some point Python gets involved and, you know, tells, tells
the rest of the system where I'm a window to draw the, you know,
to draw that buffer of characters, but that whole buffer of characters
and its management is all happens in C.
Um, so, you know, the performance aspect is completely irrelevant.
And, uh, and, uh, python gives you a lot of flexibility.
It's a great scripting language.
I know most of the scripting languages in the world.
And, uh, you know, so you can, you can stream Kitty in Python,
which is great.
And that came for free because the UI is in Python.
Um, uh, so, so like, like, like, like, for example, other, uh,
terminal terminators, mainly a compiled language, but be it Rust
or C++ or whatever, they have to bolt on scripting.
You know, you have to, you have to add a scripting engine and
then expose your native APIs to it.
Whereas in Kitty it's naturally there because everything's implemented.
The higher level APIs are all in Python already.
So yeah, you have, you have kittens written in Python, have access
to everything, out of the box, I don't have to keep like, you know,
bridging things and exposing things.
I mean, it's, it's very efficient.
Create a kitten.
If I want to extend Kitty some way, just Python, not, no, no gimmicks, just Python.
And, and it would work.
So you, you can't, you can't do things like, uh, you know, change
how Kitty parses input from the program because that happens in, in C code.
But, but the whole UI, is in Python.
So you can, you know, that's the part that users mostly care about, right?
You don't care about how to deep down the guts of the thing work. Yeah.
You care about the UI.
You care about the experience of using it and customizing it.
So that part is in Python and that, that's why it's customizable.
So I think that that worked very well.
And, uh, uh, and so, and so, so, you know, the thing that people
have against C, uh, is that it's not memory safe, but, and that's
true, it's not memory safe.
But, uh, if you're a little bit careful and disciplined, um, that,
that, that issue can be managed quite well.
So like, if you look at Kitty's security history, there have been,
1 or 2 unrelated, uh, bugs in almost a decade of history.
So
the main place that memory issues tend to bite people is in the
lifetimes of objects or pieces of data.
you forget to free something or use
something afterwards freed.
So I avoid that in the design of Kitty by mostly tying that into
Python's memory management.
So all the data structures also have a second, uh, identity as Python objects.
So the Python runtime manages their lifetimes for me.
So I can rely on it to clean it up with the garbage collection
or whatever, but all the actual hot processing happens in C.
Um, so, you know, using that, that combination, you get most of
the memory safety just by piggybacking on Python's runtime.
Um, but you can drop down to, you know, absolute, uh, speed to
the extent of send instructions on, uh, whatever.
I mean, you can see, you can do anything.
I mean, you can even write, you know, pure assembly to an embedded
thing, you see.
So it doesn't get faster than that.
So I think it's a, it's a, it's an underappreciated, but a good
combination, at least it works for me.
I always wondered, yeah.
I always wondered why I didn't feel Kitty slow since it's written
in Python, but I didn't understand like the heavy lifting and
all the power processing is done in C because I compared it with,
um, wezterm, which is written in Rust.
I think Ghosty without Tmux, the three of them, right.
Just scrolling up and down, you know, JK, just scrolling up and down.
And I was like, but Kitty is Python and I don't see it slow.
I don't feel a difference between the three, to be honest, Kitty, um, wezterm and ghostty.
There is, there is no user perceptible difference.
On all modern terminals, uh, you know, are designed with performance in mind.
So like I said, you know, 10 years back when I started Kitty,
this was not the case, a lot of core terminals left a lot of performance
on the run.
So, but the new generation of terminals all start out with performance in mind.
So they're all pretty performant.
I mean, there's not much user perceptible difference.
I mean, if you run, if you run benchmarks, you can see the difference.
But, uh, just from regular usage, you don't see any significant. Yeah.
That's what matters, what you see and what you feel. Yeah.
Now, how involved are you with, uh, both of the projects with
and, um, and Kitty, are they mainly community driven or you take
all the calls?
How does that work?
Um, so I work full time on, on open source.
So, uh, like I said, that is my day jobs.
Caliber is a huge community.
Uh, it's fun to contribute.
Engage with users. I deal with roughly about a hundred pieces of user
communication every day, day in and day out for years on end.
So, uh, and I merge PRs.
I write code.
I mean, so, so the reason I do this, like I said, I, I mean, I
started out doing this for my own use, but obviously, I mean,
they're grown far beyond that, I don't need, you know, 80% of
the features that Caliber and Kitty have for my own personal use.
Um, but you know, so those are common response to user requests
and organic growth.
Um, so, but the reason I do it is because I actually love coding.
I love programming.
I always have.
I started programming at the age of seven and I've been programming
all my life.
So it's just something I love to do.
So I make sure that I'm, you know, mostly programming.
And then I, of course, do the user emails and support and stuff.
And I merge PRs.
And yes, I am the so-called benevolent dictator for life on both those projects.
So I made the final calls and everything, but, uh, well, I'm very
open to, uh, you know, people's ideas and PRs.
You can see, if you go to the contributors page of both these
projects, there are between 100 people that have contributed code
to each project.
So, uh, you know, um, yeah, that's, that's all it works for me. Hmm. Okay. Okay.
Both of these projects have a bus factor of one.
So that's why I do so much excercise, trying to keep myself healthy. Oh, okay.
Now, um, I have a tough one for you.
I have a good question.
You want to see?
Let me, uh, let me get some water first, yep yep, grab your water first
You mentioned it.
We briefly talked about it.
I think you know what I'm going to ask probably, right?
So lemme just say it, what are your thoughts on tmux?
Oh, I, I don't have anything against tmux in particular, but terminal
multiplexers as a whole, I, I think are a bad idea.
Um, it's, the reason is quite simple.
There are two, there are two reasons.
One is, um, so a terminal multiplexer works, I mean, it is a traditional
type of terminal multiplexer like tmux, um, works by, um, essentially
implementing a terminal inside a terminal.
So every byte of data that comes from the actual terminal application
has to be interpreted by two terminals.
Obviously this is a doubling of, you know, the cost, the halving
of performance, doubling of CPU cost, whatever.
But this cant be avoided
No matter how well tmux designed it, you know, it is two terminals
in the end.
Um, so that is one, one obvious problem with terminal multiplexers.
The other more insidious problem that most users may not realize
or care about even is that, um, it makes it much harder to, uh,
design new features into the terminal ecosystem because, uh, the
terminal multiplexers, like I said, they're a second terminal, right?
So if somebody is using say kitty and tmux, for a feature to work
well, it has to be supported by both tmux and kitty, uh, and only,
only both of them cooperate and both of them implement that feature.
Does that feature actually end up in the hands of the end user
Um, and, and, and it's worse than that.
And that's because, uh, a terminal multiplexer, uh, works by essentially,
uh, rewriting the escape codes that, uh, move between the terminal
and the terminal program.
So it has to do that because, you know, it splits up the screen,
but the terminal doesn't know the screen has been split.
The terminal program doesn't know the screen has been split.
So, you know, they are both working on the assumption there's
a single screen, but to somehow make that into two screens or,
you know, movement, things like, say like a command to move the
cursor to the end of the line, a simple command, or say the beginning
of the line, even simple, that's the carriage return.
That's just a simple character, right?
Supposing you're in the right-hand side pane of a tmux split.
Now, if, if, if tmux passed that carriage return character unmodified
to the terminal below it, the cursor would actually move to the
beginning of the left pane, but the program that's running in
the right pane would have expected it to move to the beginning
of the right pane, like that's its window.
So tmux has to actually intercept that escape code and, you know,
change it to something else, changes it to a cursor movement code
that actually moves the cursor to the beginning of the right pane,
which is actually the middle of the screen as far as the terminal,
the actual terminal is concerned.
And this is the simplest possible thing.
It's the carriage return, you know, it's a really simple escape code.
There are far more complicated escape codes.
Like I told you a little bit about the kitty graphics protocol and
Unicode placeholders and kind of hacks that we had to do to get
it to work with tmux.
So, you know, it imposes that kind of cost on the entire ecosystem.
It becomes much harder, for new features to be developed and to propagate.
You know, it ends up being like, there is, there is just a couple
of gatekeepers for these features.
So like, if I want to implement some feature on my terminal and
make it available to my users, if my users are using tmux, I can't
do it because, until, unless I can convince the tmux developers
to agree with me and implement that feature too.
I mean, I can try to do some hacks like I did with the graphics
protocol, but, you know, that's suboptimal for obvious reasons.
So that is, so, you know, I think that terminal multiplexers are
a sort of drag on the ecosystem's evolution as a whole.
So that is one of the other reasons that I think that terminal
multiplexers are not a good idea.
And finally, a terminal is really a giant state machine.
There's like a huge amount of state.
You know, the current text color, the, you know, the decorations,
the underlines, the, you know, various little knobs that change
what happens when you receive escape codes.
I mean, I'm not going to go into details, but there's like a huge
amount of state that every terminal maintains.
And a terminal multiplexer not only maintains the state itself,
it has to translate this state between its own state and what,
and, you know, into some kind of state that works with its host terminal.
And each host terminal is slightly different.
You know, they have slightly different behaviors, quirks, features.
And so the terminal multiplexer has to bridge between them.
It's like an insanely complex problem.
You're sort of bridging two, you know, slightly disparate states,
very complex states, very large states.
And you do it robustly.
And so, you know, if you go to any terminal program or sophisticated
terminal programs, bug tracker, and you search for, say, tmux,
you find a whole bunch of bugs that occur only inside tmux.
Not when they're running the host terminal.
Yeah, I have experience.
So, I mean, that's kind of the practical consequence of what I'm saying.
I'm saying it abstractly like state machine and, you know, it
has to bridge things.
But the practical consequence is there are a lot of bugs that
happen because, you know, the program has to run inside a terminal multiplexer.
And that terminal multiplexer itself is running inside a terminal.
And it's just an extra layer that, in my opinion, is not worth the cost.
So, like, if I were to design a multiplexer myself, and this is
on my to-do list at some point, I might end up doing it, is I
would not try to split a single TTY into multiple windows.
Instead, I would, you know, delegate the window management to
the terminal and have a dedicated TTY per window.
So, this is much more robust.
It doesn't require all the, you know, like, for example, the carriage
return thing that I said.
It just works automatically.
So, the downside of this is that my multiplexer will only work
with, you know, one or two terminals because, you know, it requires
features from the terminal which different terminals may not have.
So, for example, kitty doesn't have this, but wezterm has its
own multiplexer, which you can use as an alternative to tmux.
So, you know, I don't know the details of how that works, but
I'm guessing it's something similar.
And so, if I were ever to make a multiplexer… So, the main use
case of multiplexers generally is the remote persistence use case.
So, you're going to SSH into a server and, you know, your network
connection is flaky, so it could go off any time.
If you lose it, if your network drops, you don't want to lose your session.
You know, the running program shouldn't end and so on.
So, that's the one thing that I would still say that tmux is somewhat useful for.
For the local use case, I'm of the opinion that multiplexers are completely anti-pattern.
You can do everything that you can do locally without the multiplexer,
just as well, if not better.
But for the remote use case, I can see the use case.
I personally would not use it.
I have other ways of dealing with this problem, but I can see
that it can be useful.
So, if I were to design a multiplexer, what I would do is I would
make it, you know, cooperate with this host terminal so that the
windowing and the splitting of this, you know, the screen, the
multiplexing part is managed by the terminal and only the session
persistence part is managed by the actual multiplexer program.
So, yeah, separation of concerns.
I mean, it is the terminal's job, after all, to, you know, put
up windows and interact with them and whatever.
So, let the terminal do that and let the multiplexer focus on
the session persistence, which is what it needs to do. Yeah.
So, you know, that would be my approach.
I have a question for you there.
The reason why I use tmux, I don't care about servers because
I don't, you know, my servers are locally.
I SSH into them.
If I lose the connection, I don't care. Right. It's fine.
That part about tmux is not important for me.
If it's a remote server, I lose the connection.
I just SSH into it again. Fine.
I don't mind about that too much.
But what I use tmux for is sessions, right?
With the keyboard shortcut, right?
Three keys that I press on my keyboard, I jump to my dotfiles.
If I press another shortcut, I jump to my, what?
Whatever, project A.
Another key, I jump to GitHub repos.
Each one of them is a GitHub repo, which is a tmux session.
That is the only reason I use tmux. Sessions.
So, you can completely replicate that using a scriptable Terminal.
I would say kitty, but I suspect you can do the same with wezterm, Kitty has a remote control API.
So, let me just show you that one.
I'll switch to your screen.
So, can you ask Kitty, okay, is this session running?
If it is running, just switch to it.
Do not create it.
Because that's the main thing, you know?
So, for example, Kitty has an ls command.
So, let me show it to you in the actual terminal, and it falls
in the documentation.
So, I'm starting Kitty.
I'm giving it that I want to allow remote control.
So, here you see, I have started Kitty.
Now, let me create a couple of windows.
Supposing in one window, I run cat.
And now, I want to check if Cat is running.
So, you can run this command, kitten @ ls
So, what this does is, it outputs a whole bunch of data in JSON
format about what windows are running.
So, you can see in here somewhere, there'll be a window one and window two.
And somewhere in there, you can see here
the title
So, you can see here the foreground processes.
So, you can see here, this window is running the kitten @ ls
command, but the next window will be running cat.
So, you can easily query this using any tool like jq or whatever.
You have that information at your disposal.
And then you can run a command like kitten @ focus-window
and you switch to that window.
So, I'm showing you the building blocks.
I'm not showing you a ready-made solution.
You have to write your own script and so on.
But the building blocks are there.
You can do all this kind of thing.
I mean, I myself use these workflows sometimes.
And like I showed you in the integrations page, there are...
But this is panes, right?
I don't use panes too much.
I use sessions.
So, a session occupies the entire screen for me.
I switch to the other session.
So, these are called OS windows in kitty.
It can focus tabs.
That's the whole screen.
It can also...
It's not showing it here, but you can also use it to focus OS windows.
So, like if you're using a hyprland or some kind of tiling window manager,
you can get from the ls command, you can get the ID of the window,
the OS window, and then you can tell your tiling window manager
to switch to that.
So, you just write a script.
Or if you don't want to use a tiling window manager, you can use tabs instead.
So, tabs work the same as that.
So, you have one session per tab, and you use a focus tab command
right here, and then you can do whatever you like.
I mean, you can build your own workflow.
So, there are no ready-made workflows for this in kitty, at least
at the moment.
But the basic building blocks are there, and you can use them
to compose your own workflow.
So, I kind of like that because I have different workflows for different scenarios.
One size doesn't fit all the scenarios.
So, in kitty, my philosophy is to give you the building blocks,
give you the remote control protocol, and a tool to control kitty,
and then you build it, use it however you like.
I mean, in fact, remote control doesn't just work within kitty.
You can use it from outside kitty.
You can even do it over a TCP port.
So, you can do it from a different computer in your house.
I mean, you can possibly design this.
So, all that is built into kitty, and those building blocks are there.
So, you can build your tools from that.
So, I was showing you the editor integration.
So, for example, vim-slime is a vim plugin that allows you to
have a LISP REPL that you can control using kitty remote control.
So, you can just send whatever you're working on to the repo in
the neighboring pane, and have it execute that kind of thing.
So, kakoune is an editor that doesn't have its own windowing, but
it integrates with tmux or with kitty or other multiplexers.
So, we use the native windows of that solution other than its own windows.
So, the building blocks are there, and people have made things with them.
So, if you wish to look into it, you can do so, and make your
own solution that your particular personal workflow. Oh, okay.
Do you talk to the tmux maintainer for compatibility when you
try to deploy something new?
Do you have communication?
What's his name?
I don't remember his name.
I did try, but he wasn't interested.
So, I don't anymore.
Now, when I make something new, I try to keep in mind the needs of multiplexers.
I have some facility in there, so I'll show you an example.
So, this is a section in the kitty website called terminal protocol extensions.
So, let's look at desktop notifications.
So, this is an extension that kitty has that allows you to show
desktop notifications on the user's desktop from the terminal
program using the escape codes.
So, there are already existing solutions, but kitty is one that
adds various features that show a button when a notification wins.
Anyway, the point is that, going all the way down, there is this
little section, identifier.
So, the thing with notifications here is that when the terminal
program sends a notification, it has a button.
The user can click that button, and then the terminal sends back
an event to the terminal program saying that this button has been clicked.
So, how is that working with the terminal multiplexer?
Because the terminal doesn't know which program inside the terminal
multiplexer has sent a thing.
So, this identifier feature is there just for that, so that terminal
multiplexers can add identifiers to these escape codes.
Like I said, they have to rewrite escape codes.
So, they rewrite the escape code adding an identifier.
And so, when the terminal responds to that notification with an
event, it sends back that identifier, and the terminal multiplexer
can read that identifier and from its own internal list, send
it to the correct window.
So, these kind of things I try to keep in mind so that multiplexers
can work with features like this.
It's not always possible to do so without cooperation from multiplexer
authors, but as much as possible, I do that.
That is one of my problems with terminal multiplexers.
It just makes everything harder.
Here, there is a dedicated channel between the terminal and the program.
So, you don't need to worry about identifiers.
You don't need to care about who sent what.
It just goes on the channel, and it's automatic.
Once you put a multiplexer in the mix, you have, okay, which window
did it come from?
If two notifications come from two different windows at the same
time, what happens?
All these sort of things you have to think about and complicates life unnecessarily. Yeah.
I think sessions is one of the main reasons why a lot of people
use Tmux still.
There's other people that do the remote server thing that you mentioned, right?
So, imagine that having a protocol that not only works in Kitty,
but works with Ghosty wezterm as well.
Like, I don't know, a session protocol that works regardless of
the terminal that you use (you see what I did there MF, planting a seed)
So, the problem with that is that it becomes a sort of lowest common denominator issue.
Then the protocol can expose only features that all the terminals
that support it have.
So, if you want a new feature, all the terminals have to agree.
And so, that becomes a break on development again.
That's a trade-off, right?
But the advantage is that then the multiplexer using that protocol
would work with all the terminals robustly.
So, I mean, it's a trade-off, right?
And different producers will be able to disagree on what end of
the trade-off makes more sense.
So, I'm very firmly of the camp that multiplexers, at least the
traditional ones like Tmux, are a bit of an anti-pattern.
I personally have been using terminals for a very long time.
And like everybody else, I was excited by my multiplexer when
I formed my workflow.
But even back then, I came across issues that were caused just
by using multiplexer that didn't happen if it were just in the terminal.
At that time, I didn't know much about it.
I didn't really understand.
But that alone was enough for me to form the opinion that this
is possibly not a good idea.
So, I avoided them in my own personal workflows.
And then when it came time for me to make my own terminal, I tried
to replicate the good parts of the multiplexers, the sessions,
the control, the flexibility, as much as possible within the terminal itself.
Because in my opinion, the terminal is the right level of abstraction
for this, the right place for window management and interacting
with the user and keyboard shortcuts, mouse actions, and so on.
It should be managed by the terminal.
The terminal is better positioned to do that than a terminal multiplexer.
So, it made sense to me.
Yeah, makes sense. Yeah.
Now, moving on to another topic that I have here, we've been here
for a long time.
How much time do you have left?
I would say about 15-20 minutes. Okay. Okay. Okay. Awesome.
I noticed the cursor animations in Kitty, they were released,
I don't know, a few months ago.
Were they inspired by Neovide?
Have you heard about Neovide?
Yeah, yeah, yeah.
So, I didn't actually make those features.
It was contributed by a user.
Let me see if I can bring it up.
Let me see.
Yes, here we go.
Here's the pull request.
So, by a user called jinhwanlazy
I don't know if I'm pronouncing that right.
So, he's made this pull request, add cursor trail feature to enhance the serviceability.
So, it was completely out of the blue for me.
I mean, I was not thinking about it.
It was not on my radar.
Some user came and suggested this feature.
And so, you know, it was quite a large feature.
We worked together and we implemented it.
Mostly, he did it.
I just provided some feedback.
And that's how it came out.
And yes, he knew about Neovide.
I think he was inspired by that.
I think if you search this page, you'll find Neovide somewhere.
There you go.
You can see right in the pull request, the very first post that's mentioned.
So, yeah, it was inspired by Neovide, but not by me. Okay, okay.
Now, I just want to know about your setup a little bit more since
we don't have a lot of time.
And I just want to have a few minutes for questions as well.
Your main IDE, which one is it?
It used to be vim, now it's neovim.
So, you can see this is a kitty file inside neovim
I mean, it used to be vim for a very long time.
But once Bram passed away, and there was some LSP.
integration in Neovim and so on, I switched to Neovim.
In fact, there's a very nice plugin for Neovim
kitty-scrollback.nvim plugin, which I'm glad to be using.
Which allows you to browse this scrollback in kitty inside Neovim
very conveniently and copy it to the keyboard, edit it, whatever.
So, when you're in a terminal, you get a lot of history, right?
So, in kitty, if you press CTRL-SHIFT-H, this opens by default in less.
So, you can search it and whatever.
So, less is the default, but it's a solid UI.
Also, you can use your own program.
And so, this allows you to use Neovim.
This plugin I'm talking about allows you to use Neovim as less
to browse the scrollback.
And so, kitty also has a feature that you can see the last command
output, for example.
If I press CTRL-SHIFT-G, the last command's output opens in less.
So, again, you can use Neovim instead and do something with it.
So, to answer your question, sorry, I got sidetracked
I use Neovim as my IDE.
So, I program primarily in Python, C, Go, my own language called
rapydscript-ng, and a little bit of Cocoa
I don't know how to pronounce that. Apple's Objective-C.
Neovim is my common IDE for all those languages.
I develop both Calibre and Kitty.
In fact, I've always used vim until I switched to neovim
So, it feels like you're trying to bring the Emacs experience
into the terminal.
Like, you're trying to make the terminal like your operating system.
Notifications, browser, everything.
What's your thoughts on Emacs?
I'm fine with Emacs.
I just prefer the modal editing experience, which is why I went
with vim
In fact, way back, the modal editing and the verbs, the motion
verbs and so on, they just clicked with my brain, so I went to vim
Once you learn something, then, you know, I've been happy with Neovim.
And talking about making everything a terminal, I pressed the
print screen key on my keyboard.
I knew that a screenshot tool, which is actually a kitty window.
And so, I'm just showing you how much I rely on Kitty in my own workflows.
Why not just come up with the kitty operating system and we just
avoid the operating system?
Someday, someday, someday.
After I write that long-promised multiplexer that includes remote persistence.
And what's your operating system of choice, by the way?
Is it Linux?
I saw macOS somewhere in there.
Yeah, no, my operating system choice is Linux.
It has been since I was 13 or something.
Ages and ages ago.
So, I have macOS and Windows machines because I write software
for both platforms as well.
But my own OS of choice is Linux.
So, like, Calibre, for example, is built for Linux, Windows and macOS.
So, the macOS and Windows build has happened in QEMU with virtual machines.
Which may not be strictly needed, I'm not sure.
So, nowadays people do that, you know, using GitHub Actions or whatever.
But I mean, Calibre is 20 plus years old.
There was no GitHub back then.
CI pipelines and stuff.
So, I had to make my own.
So, I used QEMU.
Originally, I used VMware and then I switched to QEMU.
So, now it's just, I just type in one command and it builds up
in all three platforms. Automatically.
Anyway, sorry, go on.
I know, because I was going through the Calibre's usage statistics
and I noticed that most of the users are Windows.
And I was like, why?
But you already explained that because most of the user base is
old people (sorry old reading folks, no disprespect meant, at least you guys support the man) and they are definitely on Windows.
I assume that's why, right? So, yeah.
I mean, most of everybody is on Windows.
Globally, Windows has an 80% market share of desktop and laptop computers.
Yeah, most of the users.
I mean, the Calibre usage reflects mostly that Calibres
are not techie, not in the techies particularly.
So, non-techie people use it.
And those are, they probably follow the distribution of OSs that
the general market does.
So, people often ask me, how do you make a successful open source product?
So, I often say you have to go where the users are.
So, when I made the Windows and macOS ports of the orignal libprs500, because most people
use those operating systems, so if I wanted to be successful,
I had to go where the users are.
So, kitty, for example, I don't care about it being that successful
because it's really my workflow tool (linkarzu note: and even if it was, which it is, these open source MFs don't like donating)
As you can see, I use it for everything.
So, I only bother with macOS because macOS is close to Linux,
so it's not that much effort.
People keep requesting that I port kitty to Windows, but the amount
of effort is much larger.
So, I just don't bother.
There's WSL on Windows anyway.
So, they just let them run WSL and deal with it (sorry for the 3 windows users that use kitty LMAO). All right.
So, due to time, I'm not going to continue with any other questions.
Is there anything you want to share with the audience?
Like, how can people support you?
Is this through Calibre or how can they?
Because you live off of open source, right?
I live off of open source, yes.
So, you can donate.
I know I have a Calibre website or GitHub sponsors.
Let me show you.
So, if you go to either Kitty or Calibre's GitHub page, there's
a Sponsors button.
So, there's a Sponsors Project button.
So, you can do it via GitHub.
You can do it via Patreon, LibrePay, and so on.
So, you know, whatever floats your boat.
And that's how you can keep me financially going.
And the other ways of supporting me is by contributing to the projects.
Something that stretches your own reach.
It could be a translation.
It could be documentation.
It could be code.
It could be issue triage.
So, for example, in Calibre, there's a huge community.
I have millions of users.
There's no way I can do that support myself.
So, there's a Calibre forum on this website called mobileread.com,
which I had mentioned in the introduction.
So, there are a lot of veteran Calibre users who would like to
answer user posts so that I don't have to answer everything myself.
But if you look, for example, in all of the URLs here in this
forum, you can see that I have one of the karma points for people's questions.
So, you can see how many questions I've answered.
So, you know, if you want to sort of help out with these projects,
you can, if you're an experienced user, you can join one of these
forums and answer questions.
I mean, there are Reddit forums, sort of Calibre, and the GitHub issue triage.
So, that's one way you can contribute if you're not technically
inclined in an app for whatever reason.
So, there are lots of ways of contributing.
So, like Calibre, for example, I mentioned, it has a fetching feature.
So, you can download things like, you know, New York Times or
Google News or whatever.
So, those are based on Python scripts to scrape those websites.
And so, those are maintained by users.
I tried to pitch in, but I mean, I obviously have other things to do.
So, you know, those are mostly maintained by users.
And so, you can contribute to that.
I mean, that's a relatively contained simple problem.
Yeah, the ways to contribute to open source are endless. Okay, yeah.
A lot of work, man. I see.
Those are huge projects, and you have plans.
I don't know, how you have the time, you know, to work and all that stuff?
Yeah, I have. I work all the time.
Like I said, I love to program. That's good.
Now, one last question, just to wrap it up.
And can you live off of open source?
Then you're the living proof that you can, right?
So, you mind just sharing a small, I don't know, whatever you
want to share with people.
So, I've been living off open source since I graduated from grad
school, which was about 15 years, I'd say.
And so, it's going strong.
I'm quite confident that I'll be here for 15 years more.
So, I just want to say that it's really possible to make a life
writing open source software.
Some key things that you should keep in mind is go where the users
are, and solve real problems.
Solve your own problems, especially, but your problems.
Don't try to change the world or whatever, but just find some
actual problem that you have, or that people have, and solve it.
And be dedicated, be honest, work hard, and be lucky.
That plays a part.
Calibre was so successful because I happened to be in the right
place at the right time.
That was a big part of the success.
So, you can try.
It's a nice lifestyle if you can make it work.
At the end of the day, when I look back at my life and I see how
I've done these things, I feel proud that I've made the world
a slightly better place.
So, that's a good feeling.
And it's a lifestyle where you're the own boss.
I work very hard, I spend a large fraction of my day just working.
But it's at my own convenience, at my own pace.
I can take off for a holiday anytime I want.
So that I get to spend time with my kids, with my wife, my family, friends.
So you know, though I do work hard, I also have the flexibility
to live a decent life.
That's what's important.
And you don't want to have another dictator.
You want to be the only one, right? Yeah.
You know, I'm the kind of person that likes to march to my own beat, so. Yeah, definitely.
That's a huge benefit.
Yeah source rules.
I mean, go for it if you can.
You leave a huge legacy, man, because it's huge tools, huge communities
that you're leaving or that you're creating.
So really appreciate it.
You know, even more appreciate your time being here.
I'm going to leave the links.
Well, everyone knows your tools, so I don't need even to leave
the links, but I'm going to leave them in the video description.
So if you want to share some links with me, just share them, I'll put
them in the video.
Really appreciate your time, Covid.
I hope to see you again whenever you want to share something about kitty.
Hey, there's all these new features that I have about kitty and I
want somewhere to share them.
You can come to my channel and we can do this screen sharing thing,
talking and all that stuff and you can share them with everyone.
When sessions arrive, please let me know and, you know, share them here.
Yeah, no, I don't have any links right now.
I just say, you know, find a program, doesn't have to be Calibre or kitty.
Find a program that, you know, you use and that you have good
ideas to include and go into it.
I don't want you to come and necessarily work in Calibre or kitty
and go do some open source something.
I'm not going to post any links to any of my projects, go out
there, find your own, whatever makes you happy.
All right, kovid, really appreciate it.
We'll see you till next time then. All right. Yeah.