For personal projects, I'm hosting them on <https://git.disroot.org/>. It's backed by Forgejo, and for my simple needs it's plenty.
Readit NewsYep, and that's all configuration I'd rather not have to spend time on. I was giving the Ghostty example to show how one of them Just Works™. (But the project goals might just be different, I'm not here to discredit Foot which is a really good terminal emulator.)
In defense of Foot, I installed the corresponding Nerd Font and it worked with no extra configuration at all. Well done!
> I'm aware of foot, and it works fine, but it doesn't correctly display the fancy icons used by foot (and other programs).
These are icon glyphes. You have to set the font setting for the terminal to have them. By default, foot uses whatever you set for the monospace family (you can use the command `fc-match monospace` to find out which font). You may want to use a Nerd Font instead.
Yep, and that's all configuration I'd rather not have to spend time on. I was giving the Ghostty example to show how one of them Just Works™. (But the project goals might just be different, I'm not here to discredit Foot which is a really good terminal emulator.)
Do you expect the terminal developer to know all the keybindings you currently use
i expect terminal developers to keep keybindings to a minimum.
come to think of it, i can't think if a single keybinding that i need from a gui terminal. the only keybindings i need from a terminal are those for tmux, so if a terminal replaces tmux (like wezterm is able to) then those are ok, but otherwise when i run tmux in a gnome terminal then there isn't a single key binding that i need for gnome, except possibly copy and paste.
Precisely this. With OSC-52 you don't even need copy/paste keybindings under tmux.
> I like that I can use tmux locally and remotely and thus have the same interface wherever I do my work
> (e.g. recently I was again trying to use flow <https://github.com/neurocyte/flow> and its next-tab and previous-tab shortcuts clash with Ghostty's)
Like I use vim so frequently hit <C-w> while typing and when I'm not on mac I kill browser tabs (probably for the best lol). But the benefit of all CLI programs is the config. There's no "one-size-fits-all" solution, so having configuration is the next best thing.
> If I had a terminal that
> I don't think I understand this example. There's only so many keybindings and clashes aren't uncommon.
That's precisely my point! Many terminals these days try to do too much and by default end up capturing keybindings that I want to use for something else. The terminal should allow me to do that something else, not get in the way. A simple terminal wouldn't get in my way and I could insert tmux in the more complex scenarios (even for local sessions). I know I can reconfigure most terminals, but not everything is configurable, plus everyone knows the best tools are the ones that don't require to be reconfigured to be great. :)
Thankfully my main editor is Helix and by default it doesn't clash with anything because it's a modal editor where commands are regular keystrokes and not key combinations.
> Foot is a barebones solution, so that might be good for you
I'm aware of foot, and it works fine, but it doesn't correctly display the fancy icons used by foot (and other programs). For a visual comparison, here's foot on the left, Ghostty on the right: <https://v1.imgpaste.net/images/public/21baee04-b4a5-4693-8a8...>
So many people miss the point of tmux.
The only reason to still use tmux (or screen) is because you use remote sessions. All modern terminal emulators are already capable of doing tabs and panes (okay, maybe not sessions, but some can locally). If you're using tmux for this reason, stop. Go pick up a modern terminal like ghostty, Alacritty, or WezTerm.
But why tmux still exists today is because people are working on computers they aren't sitting in front of. Because I don't want to have to be running nohup or detaching, moving to the background, and resetting the session so error messages don't appear in my active instance. Hell, technically I can do this with vim and get something pretty similar to tmux by using the terminal. But that's a pain.
Tmux is for *terminals*
I would mostly agree, but I like that I can use tmux locally and remotely and thus have the same interface wherever I do my work (and regardless of what terminal I use).
Then, there's the fact that some terminals capture too many keybindings and get in the way of some terminal code editors I'd like to use (e.g. recently I was again trying to use flow <https://github.com/neurocyte/flow> and its next-tab and previous-tab shortcuts clash with Ghostty's). If I had a terminal that 1) was nothing but a black box with the capability to display Unicode font glyphs and ligatures correctly, 2) works under Wayland, and 3) captures as few keybindings as possible, I'd use it locally with tmux and live happy.
The web is UTF-16 ? WTF
JavaScript is: https://mathiasbynens.be/notes/javascript-encoding
osmsucks commented on How to configure X11 in a simple way eugene-andrienko.com/en/i... · Posted by u/speckx
I was there, Gandalf. I was there 3000 years ago, when we edited ~~x11~~ xorg config files by hand. I will gladly pay any price in bloat to never have to touch that nonsense again.
I remember having to write XF86Config by hand.
EDIT: of course there's an xkcd for that: https://xkcd.com/963
osmsucks commented on I'm dialing back my LLM usage zed.dev/blog/dialing-back... · Posted by u/sagacity
I think LLMs have made a lot of developers forget the lessons in "Simple Made Easy":
https://www.youtube.com/watch?v=SxdOUGdseq4
LLMs seem to be really good at reproducing the classic Ball of Mud, that can't really be refactored or understood.
There's a lot of power in creating simple components that interact with other simple components to produce complex functionality. While each component is easy to understand and debug and predict its performance. The trick is to figure out how to decompose your complex problem into these simple components and their interactions.
I suppose once LLMs get really good at that skill, will be when we really won't need developers any more.
> LLMs seem to be really good at reproducing the classic Ball of Mud, that can't really be refactored or understood.
This, but but only for code. I've seen "leaders" at work suggest that we "embrace" AI, even for handling production systems and managing their complexity. That's like saying: "We've built this obscure, inscrutable system, therefore we need another obscure, inscrutable system on top of it in order to understand it!". To me, this sounds deranged, but the amount of gaslighting that's going on also makes you think you're the only to believe that...
More: