A while ago I started to build something similar, but I didn't get much farther than choosing a name for the project (https://github.com/mk12/loopy). I want to design a language that can specify patterns precisely and unambiguously, and then visualize them in a physically accurate way. For basic 2D patterns I was thinking I could render each stitch based on it and its neighbors (3x3 grid of K/P). But that wouldn't be that useful. What would really be neat is to use a physics engine to simulate the yarn in 3D. For example the simulations would show stockinette curling and ribbing stretching without that being hardcoded anywhere. But I think it's too hard and I have no idea where to start with that.
There are lots of terminal projects recently. Ghostty (https://mitchellh.com/ghostty) and Terminal Click (https://terminal.click) come to mind. Also Warp and Fig but they don't appeal to me because they're proprietary (and Fig got acquired by Amazon). I've been very happy with kitty (https://sw.kovidgoyal.net/kitty/) for years and it would take a lot to make me switch.
I switched to wezterm (https://wezfurlong.org/wezterm/) a few months ago and I'm pretty pleased with it (especially the search function, which is something not many terminals support), although it still has some rough edges.
I've used kitty for quite a while but it has subtle problems with tmux that I use all the time (one of the primary reason is persistent session).
From the FAQ https://sw.kovidgoyal.net/kitty/faq/ and other GitHub issues, it seems the recommendation is not to use tmux. Since I need to use tmux, I then change the terminal emulator I use instead.
The one I encountered is color problem. I can never get xterm-256color works reliably and has to use screen-256color which supports lesser features such as italic.
Running btop within tmux using kitty also has color problems, but Alacritty also fails at that.
I had a long battle with making kitty work with tmux. I settled on the following in ~/.tmux.conf, before moving to wezterm for good. Maybe it fixes things for you, too:
I tried the first line and in some situations (specifically with some remotes, i.e. kitty -> ssh -> tmux with that 1st line) it still won't fix it.
I gave up kitty because the author obviously don't like tmux and is advising users not to use it. So it is more like a choice between kitty and tmux. Giving up kitty is easier for me in terms of features and time for retraining.
What's your reason to migrate from kitty to wezterm?
> What's your reason to migrate from kitty to wezterm?
My reason to no longer using kitty is simple: I don't like having to copy kitty's terminfo data to every single system I connect to in order to have my terminal work.
It's fine for those few systems I very often connect to, of course.
But I also connect to ephemeral systems, sometimes for a short session, and the toil and friction inherent in having to do that just isn't worth it.
Sure, "kitty +kitten ssh ..." can work in most people's scenarios. Didn't quite work in mine, due to various intricacies about my ssh setup - multiple ssh keys, handled mostly by ssh-ident.
wezterm Just Worked for me. As I got "back" to also using other systems like Windows and MacOS, it Just Worked there, too. No fiddling with terminfo, no fiddling with $TERM, either.
I tried your solution using one remote server that I had trouble with before and it works! That's really great. This probably solves enough problems with kitty for me that I can use it until I find a better solution. (I am using Alacritty at the moment but it has other problems so that I have to use kitty as fall back for some situations.)
Colors in terminals are tough. There's the terminal, then the shell, then tmux, then vim, and you want all of their configs in concert even when you're switching between light and dark one or twice a day. Colors are tough in general. Even the browser color story kind of sucks. Dark reader goes a long way, but not enough
Right, I sort of understand that (not the details). I'm sympathetic to the kitty author, who explains why other terminals and tmux are doing things wrong, etc.
I guess it is especially messy in the terminal, reading a little bit into the issues and it just feels like a ton of legacy hacks between different implementations.
And comparing that to the browser is interesting. Both are "ubiquitous"—terminal emulator for cli/TUI, and browser for GUI. May be because of there generality / ubiquity, it is messy and impossible to "make it right".
> That's a pretty hyper-optimized life, when 0.2 sec to get a command line is a problem.
This made me chuckle :D. I supposed you're right. On my work rig, 200ms is a dream, so I suppose kitty would be great.
For personal programming, I use i3 and sway. The latency difference between my work mac and personal Linux is insane. Every little bit feels like molasses on Linux since it's the lowest latency system I've ever used.
Great point. I was using i3/sway which is not conducive to terminal tabs or panes, but on my mac, kitty does sound pretty good, and 200ms is way better than what I'm getting now
Kitty's my daily driver on Mac (when I'm not using eshell, anyway), but on the Windows side I am actually pretty damn impressed with Windows Terminal over WSL2. I don't even bother using graphical mode on emacs in WT/WSL, it is smooth as butter and super responsive in terminal mode and aside from using Linux, I'm actually preferring it as a dev environment to a Mac these days.
In fact, it feels like there's an ever-so-slight latency when on a Mac that Windows doesn't have. At first I put it down to the keyboard feel, but even using the same keeb it feels a bit more 'squishy' on the Mac.
I really like Windows Terminal too. The one issue I have is that I have Ubuntu as the default session and when I open the terminal from the start menu (i.e., hit command key, type "terminal", and hit enter), it opens but loses focus. The only way to remedy it is to disable WSLg (GUI support). It's a long standing bug and a weird one at that.
Yeah, that and sometimes the WSL session takes forever to boot up (a good 10+ seconds for the first time, for me).
Once it's working it's fantastic. I don't know what it is with MacOS, unless they're subtly animating keypresses or something. Linux is as responsive as Windows is too. It's a wired keyboard so nothing to do with bluetooth.
I wasn't crazy about the proprietary nature of Warp, but I tried it and was sold almost immediately. I can use the same modifier-key commands to select and manipulate text that I'm used to, which feels super nice. They also provide such good sessionization out of the box that I don't really feel the need to install tmux or anything like that.
The problem is that Warp is closed source, requires a log in, has extensive telemetry, promised to go open source but never did and has raised 78M from VCs including 50M from Sequoia, the FTX people.
Indeed, VCs will want a return on their investment at some point, and it doesn't seem like simply sharing some terminal commands in the cloud with your team will be enough to justify that valuation. This is especially true as the Zero Interest Rate Phenomenon of the last 15 years is now over.
Personally I'd never use something VC backed for something so critical to my productivity.
Having never heard of Warp and wondering what would get VCs to give that much to a terminal project I just took look at their website and it’s obviously the AI/LLM aspect.
With that said does anyone know which open source projects are looking at LLM integration. It’s not a bad idea.
I took a look before this year and it used to be that their value proposition was more so geared towards sharing terminal inputs and outputs easily. Now they seem to be leveraging OpenAI APIs instead as their main value prop.
However, I still don't really see why someone would pay 12 bucks a month for that when they could just pay a little bit more for full blown ChatGPT and use AI for much more than terminal commands (and there are already terminal and vim plugins to directly query GPT with your API key, which is orders of magnitudes cheaper than Warp). It seems like a product that has no clear target market or target usage, seems more like a feature than a full product.
Thankfully it doesn't run it, it just inserts the commands into your prompt. It's kinda nice but I've also been using the terminal for like 12 years, so I don't find myself relying on it very often.
I can just run Llama locally for that, no VC required (and indeed there are plugins which do exactly this already). Llama and other local LLMs are being optimized to run on the CPU on less than 1 GB of RAM so it's not as if only those with beefy GPUs can do so.
Agreed and the part I’m missing is these plugins which do this. Any suggestions or recommendations would be interesting to hear. Which terminals and which plugins etc.
> I can use the same modifier-key commands to select and manipulate text that I'm used to, which feels super nice.
I know this is not a complete solution, but just in case you weren’t aware, the keybindings in GNU Readline are nearly entirely configurable[1]. Getting some of the keybindings to work could require digging into serial terminal arcana[2], unfortunately, but here a terminal emulator that supports either the Kitty keyboard protocol[3] or the (venerable if impressively badly documented) modifyOtherKeys feature[4] could make things easier (messing with the serial driver[2] seems an overreaction to me, and you can’t get acceptable Ctrl-C behaviour that way anyway). The “new” terminal emulators mentioned in this thread (alacritty, contour, kitty, wezterm) should be able to do the trick, and of course xterm as well (probably rxvt too?); tmux compat needs help, though[5].
Seconding kitty, a while ago I tried like a dozen of different terminal emulators and tested a lot of features including link clicking, escape code rendering, Unicode rendering and so on, and only kitty and Sakura have passed most of my requirements, with Sakura having one issue that I cannot recall that ultimately made me choose kitty. Built-in window splitting without tmux is also great. The only downside is that when you SSH into a remote machine without kitty's terminfo installed, you can't even use backspace or other common keys, which is annoying.
I went wezterm because kitty wasnt always playing nice with tmux and i dont think i would go back at this point there is something i juat like more about wezterm i cant put my finger on.
I don't care what language Homebrew uses, it just works. When I got my M1 MacBook in 2021 I saw some of this negativity about Homebrew, and since I was doing a clean install anyway I decided to try out MacPorts. I quickly ran into problems and switched back to Homebrew and it's been smooth sailing.
What problems did you run into? I've been using MacPorts for years at this point since Homebrew can never seem to install libraries in a way that pkg-config, gcc, and ld can find them. (Yes, I'm aware there is a subcommand in brew to manually print the paths to libraries, this is still not ergonomic compared to MacPorts where I install a library and it more or less "just works" when I want to use it).
Also, Homebrew attempting to nuke /usr/local on uninstall left a quite bad taste in my mouth. I had installed MacTeX before Homebrew, and thankfully MacTeX had proper file permissions set up, so my TeX installation was left in-tact. Still scary knowing that this is just done in the background without warning (unless the operation fails with errors).
It makes a mess out of iconv because it's not compatible with the OSX bundled version. Without digging into it further it seems like the macports iconv headers and libraries shouldn't be in the default search path.
I listened to that, it was good! I was surprised there is an entire podcast about array programming. Looking forward to future episodes, and also to trying AoC with BQN again in a few months.
I recently found out about another project called jj: https://github.com/martinvonz/jj. It takes inspiration from Pijul and others but is git-compatible.
Came here to praise jj as well. More than just "git-compatible", its backing store is literally git, which means that you can transparently collab with existing git repos to your heart's desire.
Other interesting ideas it implements:
- Working copy always comitted,
- All repo operations are version controlled, which enables painless undo etc.
- First-class conflicts, just like pijul, so no merge/rebase/etc ops every fail
- Auto-rebase of downstream dependent branches when doing rebase etc.
Also, the dev is really active and helpful. Apparently, Google let him make the project his full time job.
