I used Alacritty and Fish before and I’m not interested into the features and complexity of BTRFS. Alacritty is a fine editor and wouldn’t mind using, but it lacks features to me and there are better alternatives. I would prefer Kitty. Right now I use Konsole and that’s good. Fish on the other hand, is more problematic to me. I use the terminal a lot and I am used to Bash, even write lot of Bash scripts. They are very similar, but still different and not compatible; so for me its a struggle in the terminal to remember the differences between Fish and Bash. There is 0 reason for me to use Fish and prefer Bash.
Is there any particular reason why you prefer that one specifically? Out of all the newer terminal emulators I have tried, the only one I disliked more than kitty was warp.
It’s the only terminal emulator that has consistently worked without bugs for me out of all the terminal emulators I’ve tried. And I’ve tried soooo many. Probably about 20, given them all serious time and a real shot, configuring each to my liking.
One thing I don’t like about Kitty is its configuration file format. 🫤
I used both when I was a tiling window manager user. Kitty is feature rich and has everything I would want. I would prefer over Alacritty, because I miss feature. However on my last OS installation, I kept Konsole (from KDE) as terminal emulator before I did all the basic setups and was planning on installing Kitty again. But it turned out that Konsole is excellent and there was no need to change, so kept using it.
The protocols designed for Kitty are great, but I when I last gave Kitty itself a try, I felt it was extremely opinionated in a very off-putting way.
It was advertised as being highly extensible and scriptable, but despite that, I found it to be less flexible than my old setup which wired up tmux with Python scripts. For instance, I was able to track which pane was previously active when creating a new split, allowing me to have the newly-created pane’s bashrc read the old pane’s bash /proc/ entry to copy the environment variables. That wasn’t possible in Kitty. And although Kitty’s splits layout were functional, resizing the splits themselves was an unconfigurable pain in the ass because the sizing is based on width/height rather than bounding boxes.
I would normally chalk that up to growing pains of a new project, but reading through the GitHub issues and documentation didn’t leave me with the impression that the author cared about how something could be done in Kitty, but only that it could be done in the most basic sense. If the user’s workflow would benefit from having a partial overlay or popup, tough shit—they can either use a full overlay or create a layout for it.
It didn’t sit well with me, and moving to Kitty full time would have been a downgrade in productivity for practically no real benefit.
I used Alacritty and Fish before and I’m not interested into the features and complexity of BTRFS. Alacritty is a fine editor and wouldn’t mind using, but it lacks features to me and there are better alternatives. I would prefer Kitty. Right now I use Konsole and that’s good. Fish on the other hand, is more problematic to me. I use the terminal a lot and I am used to Bash, even write lot of Bash scripts. They are very similar, but still different and not compatible; so for me its a struggle in the terminal to remember the differences between Fish and Bash. There is 0 reason for me to use Fish and prefer Bash.
Is there any particular reason why you prefer that one specifically? Out of all the newer terminal emulators I have tried, the only one I disliked more than kitty was warp.
I’m not the one you asked, but I use Kitty.
It’s the only terminal emulator that has consistently worked without bugs for me out of all the terminal emulators I’ve tried. And I’ve tried soooo many. Probably about 20, given them all serious time and a real shot, configuring each to my liking.
One thing I don’t like about Kitty is its configuration file format. 🫤
I used both when I was a tiling window manager user. Kitty is feature rich and has everything I would want. I would prefer over Alacritty, because I miss feature. However on my last OS installation, I kept Konsole (from KDE) as terminal emulator before I did all the basic setups and was planning on installing Kitty again. But it turned out that Konsole is excellent and there was no need to change, so kept using it.
Why did you dislike Kitty?
The protocols designed for Kitty are great, but I when I last gave Kitty itself a try, I felt it was extremely opinionated in a very off-putting way.
It was advertised as being highly extensible and scriptable, but despite that, I found it to be less flexible than my old setup which wired up tmux with Python scripts. For instance, I was able to track which pane was previously active when creating a new split, allowing me to have the newly-created pane’s bashrc read the old pane’s bash /proc/ entry to copy the environment variables. That wasn’t possible in Kitty. And although Kitty’s splits layout were functional, resizing the splits themselves was an unconfigurable pain in the ass because the sizing is based on width/height rather than bounding boxes.
I would normally chalk that up to growing pains of a new project, but reading through the GitHub issues and documentation didn’t leave me with the impression that the author cared about how something could be done in Kitty, but only that it could be done in the most basic sense. If the user’s workflow would benefit from having a partial overlay or popup, tough shit—they can either use a full overlay or create a layout for it.
It didn’t sit well with me, and moving to Kitty full time would have been a downgrade in productivity for practically no real benefit.