If emacs wasn’t really slow with long lines in buffers and high volume output, it could be better
What is this? I've been using iterm2 for years and don't know about this (and can't seem to find anything mentioning it).
“Tables” is imprecise, but is one use-case: it’s more about identifying soft boundaries like the lines between tmux or vim splits and limiting the selection to one side of the split. If you have pipe-delimited tables, it lets you select a single column of values.
Interpretation of intent and “helping” the user are neither needed nor desired, and at best leave everything alone and at worst misinterpret and get in the way.
I have never copied anything out of a terminal and gotten anything other than what I copied when I pasted into sublime text, and I’ve never used iterm2.
Are you talking about copying from a terminal and pasting into OneNote or some other “more than plain text” application or something?
This is the single feature I miss the most in any other terminal emulator.
The iTerm2 feature being discussed means that selecting works the same way it does for graphical programs like Gedit or Pycharm or Word — if you select 10 lines you select 10 lines and your window size, font size and visual wrap setting don’t factor into it, and when you paste, you paste what you copied as it was. I would say this is the intuitive and reasonable behavior, but it’s one that is not simple to implement. A visual word wrap should be a purely visual thing and s back to back Cut and Paste should result in nothing changing.
Does that include all trailing whitespace in the rectangle you selected? Should your selection automatically minimize to unselect said trailing whitespace (even before copying, I mean)? Should a selection preserve tab characters or replace them with spaces? What if the selection does not start at a tab boundary, should it ignore or include the half-selected tab instance?
I don't think there is a singular answer to what "copy selection verbatim" means.
A couple years ago, I tried this in kitty and a couple other Linux terminals and none of them implemented this.
IMO this setting belongs with the application, and especially with tmux and nvim supporting this natively, you don't really need the terminal itself to implement some potentially fallible heuristic. For example with iTerm if you accidentally drag outside the pane boundary, the selection immediately expands to include both the panes, which is not ideal.
Sometime in the last year, iterm2 started adding ~00~ crap around stuff I paste. then some yellow 'alert' box at the top indicating I'm doing something wrong and do I want to keep doing it. makes 0 sense to me, and... annoying because it didn't do it for the first... 6-7+ years I used it. My behaviour didn't change, but iterm2 starts breaking.
No doubt there's some 100% logical explanation as to what changed such that my standard copy/paste is 'wrong' now, but... would have preferred they'd have kept the original behaviour.
There’s a toggle in the terminal settings
Wezterm terminal supports multiplexing from the box: https://wezfurlong.org/wezterm/multiplexing.HTML
Also, there is Hyper terminal, and standalone protocol to implement multiplexing https://www.reddit.com/r/commandline/comments/q5mj11/htm_a_c...
If you know other options, please share.
I work in windows, but at home I use macos, so I stick to wezterm. I use it with single config for both platforms (config is written in Lua)
If you are hoping to new machines every time then sure.
But lets be honest, thats a minority.
I don't know kitty in specific, but wezterm ie. can connect to target via SSH, start daemon of itself there and actually work better then tmux, because it's controlled from the client (where the gui runs), but with all the tmux upsides.
And yes, it's not as portable as tmux (simply because its not as popular), but again, in majority of the situations the setup required is really not that much. Especially if you would spend that time on tmux config anyway.
The thing I like about tmux and zellij is persistence and the "task-runner" nature of them. Its great for managing sessions and running things in the background. Though I do hate how they also break a lot of features that I do like about terminals.
Sadly, that seems to leave me with only 2 options that work well over SSH:
- using a terminal with client-server model and built-in multiplexer (VSCode Remote SSH extension, WezTerm)
- using iTerm2 with tmux integration (apparently nothing else implements tmux control protocol https://unix.stackexchange.com/a/280829)
BTW this is the first time I've seen a working drag and drop TUI (you can use drag-and-drop to move floating panes around).
[0] https://zellij.dev/tutorials/basic-functionality/ [1] https://github.com/sponsors/imsnif
I found out about it from this blog post nearly two decades ago: http://web.archive.org/web/20190120170204/http://www.termina...
set-option -g mouse on
Then you can create new windows or panes by right-clicking (and clicking on the drop down), click on a pane to focus it, click on a window name to focus it, right-click to rename it, drag to highlight text or to adjust the width of a pane, etc, etc.
Kovid Goyal has a history of being incredibly opinionated to the point of being combative and toxic at times. He makes some great software, I’m a user of kitty, but this hyperbolic tone about this issue is not shocking to me at all.
https://bugs.launchpad.net/calibre/+bug/1714107
There are a lot of other gems too if you look through Calibre's bug tracker
https://bugs.launchpad.net/calibre/+bug/885027
I myself use 2 terminals: Alacritty and WezTerm. The former for local work, and the latter for my VMs, and occasional remote server work.
I couldn't explain exactly why I use separated applications, since WezTerm works well for local (which even has a menu entry for that) and remote alike, but I'm comfortable with the workflow that I have today, and for me it's enough and what matters.
Both are actively maintained and can work with modern terminals, as long as the hosting terminal is standards compliant.
I don't understand why people love to break standards.
I don't agree with this. There are tons of standards (even if it's de-facto) from VTxxx to XTerm's emulation standards. If there were no standards, it wouldn't be possible to talk with a modern system using a real VT320 (Yes, we have these), or with a vintage system with a modern terminal over a TTYUSB device.
> The problem happens when someone wants to add something new to the terminal ecosystem.
I understand, but every decent standard should take what's done before them and be prepared to face with it. Let it be Ethernet, TTY, even something modern like DisplayPort. When people doesn't do their due diligence and spend the time required to handle edge cases, things are bound to break (e.g. Cheap monitors' firmware contains identical serial numbers, causing all types of shenanigans in multi-monitor setups).
> 2a) Designing something becomes harder because it has to be designed to work with the horrible hack that is terminal multiplxer.
For harder part, see the previous paragraph. i.e.: One should do their homework to work with other systems. On the oh gawd horrible hack! part, That "horrible hack" is saving hours of work per month per person who work with remote servers for ~30 years now, and nobody is planning to give them up AFAICS.
> The tty model is dead simple, one tty per child process. When you add a terminal multiplxer it completely confuses this simplicity, making it instead multiple processes per tty and does it in a way that is opaque to both the processes and the host terminal, leading to endless bug and incompatibilities.
Maybe one should draft a new standard about multiplexing terminals persistently without it being a hack? There's a big gap there, as you point out.
> 2b) Any new feature is now gatekept by the individuals in charge of the multiplexer projects.
Both screen and tmux are maintained properly, and they fix the bugs they cause actively. For example, screen was causing a problem in SGR mode, and they fixed it 2 months ago [0].
Oh, on SGR; it's an ECMA Standard. Standard-48 to be more precise [1]. So, again, there are standards, and you can build new ones, and I bet, terminal multiplexers will play along if you don't throw eggs at them.
[0]: https://git.savannah.gnu.org/cgit/screen.git/commit/?id=c184...
[1]: https://www.ecma-international.org/wp-content/uploads/ECMA-4...
I suggest you go plug a VGA cable into a DisplayPort and see what happens.
The horrible hack is saving you and the few other very loud people that use it hours of work. I for instance have been using remote servers for 40 years without ever needing a multiplexer. They have always been, and remain, horrible hacks that I rejected when I first came across them and that have been a drag on the entire terminal ecosystem for 30 years. Thankfully they are finally on their way out, thanks to a new generation of terminal emulators and are using the tty the way it was designed to be used.
The new standard is the old one. Use the tty as it was intended and designed without a horrible hack in the middle. And if you really need remote persistence via a multiplexer of all things, then use one provided by the terminal emulator you use so that it integrates natively, seamlessly and correctly with the terminal emulator. Granted currently only WezTerm provides such a multiplexer, kitty for instance instead multiplexes SSH access via SSH control masters. But its developer has indicated he will someday write a tmux replacement that is kitty native.
Oh and on SGR it is an ECMA standard, only in the breach. For example, color support as it is actually used in terminals violates the so called specification.
As for multiplxers playing along, here you go: https://github.com/tmux/tmux/issues/1391
Complete and utter drag on the ecosystem.
OK. Let's look what happened some of these opinions.
- PDF became two different ISO standards.
- USB started as a de facto charging port, became de jure in EU.
- DMX, MIDI, DE-9 RS232 connectors are all de-facto standards, but used as de-jure now.
- Tons of file formats in scientific and engineering computing is in fact de-facto standards, yet they flourish.
> I suggest you go plug a VGA cable into a DisplayPort and see what happens.
I use something similar to this [0]. It works.
> The horrible hack is saving you and the few other very loud people that use it hours of work.
I love how you liberally throw the h-word around. Because horrible hacks became conventions over history. Vi's latency hiding can be considered "a horrible hack", or "brilliant" depending on the perspective. Same can be said for HDMI for example. Piggybacking on DVI for video signalization, adding a couple of digital lanes for sound and Ethernet, it can be considered a horrible hack, yet it's a de-jure industry standard. IOW, someone's opinion, just in a written form with some stamps and a logo.
From my vantage point, people not using terminal multiplexers (tmux/screen) are a shrinking minority, yet from your perspective it's the opposite. Considering the oh gawd horrible terminal multiplexers are still maintained, and I still initiate people on screen or show them tmux as a screen alternative, I don't see they're going anywhere. Your perspective may differ. I'm mostly talking about younger generations, I may add.
> I for instance have been using remote servers for 40 years without ever needing a multiplexer.
I think you're lucky for not having to debug things on the go, for days, or managing servers on a responsive and stable network. I sometimes have no luxuries, so I have to use horrible, horrible hacks to get things done. It works brilliantly unfortunately. Shame on me.
> I rejected when I first came across them and that have been a drag on the entire terminal ecosystem for 30 years.
That's a long grudge to hold. I'm sure it's not the only one. Think about your health. No it's not meant to snark. I'm honest.
> Thankfully they are finally on their way out, thanks to a new generation of terminal emulators and are using the tty the way it was designed to be used.
I don't see it's happening, sorry. What I see is more hacks are piled upon hacks. Some might stick and become standards, some might die.
> Granted currently only WezTerm provides such a multiplexer...
Wezterm's multiplexer is a regular old multiplexer which connects to a remote wezterm instance. IOW, just a different transport which encapsulates a WezTerm instance. There's nothing magic here. It's moving the hack to another layer. Now there are two transports, and Wezterm's one is not interoperable with others. So it's a really horrible hack from my perspective. If something is not interoperable with other tools, then it's out for me. I can't be bothered to install Wezterm to all and every server I work with. Which is >1000.
Unfortunately, I have the luxury of choosing the terminal which I want to work with in any circumstance. As long as I can connect to my remote server, my persistent workspace is there. I don't need a local Wezterm to be able to work.
> ...without a horrible hack in the middle.
Wezterm puts the horrible hack on top. Like a cherry. Bright and eye-catching, in a bad way.
> As for multiplxers[sic] playing along, here you go: https://github.com/tmux/tmux/issues/1391
I read the bug report. I think the problem is the approach. If somebody is so adamant in a feature, and the maintainer doesn't want to add that feature, a) you can patch it yourself, b) you can fork and patch it yourself. It's free software. The tmux maintainers doesn't owe you anything. I bet, if you send in a nice patch, they won't ghost/reject you.
BTW, a mux is just another terminal emulator inside your terminal. It's not more of an hack compared to an ncurses window, or old graphic interfaces in UNIX systems.
> Oh and on SGR it is an ECMA standard, only in the breach.
Many standards are flexed. Many graphics cards do not fit inside the PCIe mechanical standard, for example, but they work.
> For example, color support as it is actually used in terminals violates the so called specification.
My terminal has fallbacks for a lot of modes. This is what backwards compatibility is for.
> Complete and utter drag on the ecosystem.
Sorry I don't see/feel it for the last 20 years.
So, in short, I agree to disagree, and genuinely wish more power to you in your endeavors. There are no hard feelings here, just tone-matching.
Hope to have a longer chat and have the opportunity to learn from each other.
Cheers!
[0]: https://media.startech.com/cms/products/gallery_large/dp2vga...
1) The difference between WezTerm's multiplexing and say tmux, is that wezterm's multiplexing supports all the same features/bugs/syntax and quirks as WezTerm itself. It does not have to translate between what it gets from an unrelated terminal implementation that it has only the most superficial information about to its own internal representation and back, which is what a multiplexer like tmux has to do. Tomorrow if Wez decides to add a new feature to WezTerm, he can add it to his multiplexer at the same time. Thus, the WezTerm multiplexer is a) much more robust than tmux b) not a drag on the entire ecosystem since nothing other than WezTerm itself depends on it implementing anything.
And therefore, unlike tmux, it is not a horrible hack.
To put it another way, tty's are sufficiently complex that multiplexing if needed at all, must be done by the terminal emulator, not an unrelated third party sitting in the middle. You say a multiplexer is another terminal inside the first, I say that is precisely the problem. It is an incompatible terminal emulator.
The protocols introduced by Kitty, like the Kitty Graphics Protocol and Kitty Keyboard Protocol, were sufficiently well-documented that other modern terminals (e.g. WezTerm) have adopted them as well. Moreover, both protocols offer advantages cf. the modifyOtherKeys and Sixel standards used by e.g. xterm.
The main problem with Tmux that no one talks about is its arcane configuration and interaction patterns. If you set up a ton of config while gritting your teeth, it begins to work well, but the configuration semantics are a nightmare. I would love something similar to tmux that has sane configuration and theming. I switched from XMonad to i3 for the same reason.
Since I keep my configs in a repo, I just checked the last time I changed my `.tmux.conf`. Turns out it was 2018, and I changed a grand total of 2 lines. And I use tmux daily, not just remote, but also on my local machine.
So yeah, if I am using something for more than half a decade without requiring any change, then its pretty safe to say that whatever hassles the configuration of that something imposes, is completely irrelevant.
It’s not only the config, though. It’s the arcane shortcuts and the weird way it seems to handle most things (trying to get the mouse working is a bloody nightmare and it regularly borks the terminal). I have a mouse with a scrolling wheel, for example. It works fine with most programs over ssh, why is it such a pain with tmux? Such pains remain even after having felt down the rabbit hole and spent 2 weeks tweaking settings.
iTerm2 is fantastic and I would be very happy to just use it and call the problem solved, but I don’t have a Mac at work.
It's literally one line of config.
> It’s the arcane shortcuts and the weird way it seems to handle most things
Tmux is a TUI and the shell and other software running on it are themselves TUI. There will be conflict and the prefix solution is actually simple. Tmux solves one particular problem and solves it well. It's on you if you want it to be something else.
All of which can be configured.
More often than I’d like! tmux config has broken backwards compatibility on me multiple times over the years.
This is fine for most software — you upgrade your config once and you’re done. However, the nature of tmux is that I use it on many servers, some old and some new, some with tmux 1.x and some with 2.x. Getting a ~/.tmux.conf from my dotfiles repo that works across both has been papercutty.
Love tmux though & can’t imagine tty life without it — I run it locally as well as on remote machines.
My home git log shows my first tmux configuration was in 2017. Since then, several options have been removed, they now throw an error on startup, and mess with muscle memory for key bindings that are essential to using a program like this.
This means that to get tmux working properly again I have to catch up on years of release notes to figure out what I'm supposed to change. I have never once had to do this with screen despite using it for over 20 years.
Any time my muscle memory is betrayed, I give up and go back to screen and don't bother touching tmux again for several months.
It’s a tmux plugin that replaces the default Ctrl-b keybindings with the same keybindings used in i3wm (including turning on automatic tiling instead of manual splitting). Given that you use i3wm on your desktop, you might like it :)
The cynic in me thinks it's more likely that because kitty offers tmux features he wants to lock users in to his product.
But it's also foss, so, you're still right.
My God, what have we done
Yes efficiency is good. But... Damnit man! The performance numbers shown for this low power processor are 43MB/s without tmux vs 30MB/s with tmux. It's likely going to take a lot of activity for that to aggregate into even a decent fraction of a ms of latency.
Beware extremists. Some people will never be pleased, will accept nothing. The only answer is to cut cut cut forever. There's a cult of people out there that idolize performance above any practical use like a god & will destroy & savage anything else. Deny this falsity. Respect performance, but also allow other factors to balance in.
(Side note: I'd love to know how dtach performs. It has the key advantage to me of tmux, which is detachability, but no virtualization. Great for running a vim session! And by design is a very pure simple pass through.)
Also, latency is not a direct function of throughput. The two are separate. In this case the latency will come because when you have tmux in the middle it means your command line program writes to a pipe, which is a buffer in the kernel. tmux then has to read from that pipe, then it has to process that byte updating its internal state, then it has to generate the output bytes based on the internal state, those output bytes are written to another pipe, and finally the terminal reads from that second pipe.
There is a whole extra pipe with associated context switches for every byte (or more accurately every packet since reads/writes on a pipe are buffered). This will add latency for example for every keystroke no matter what the throughput numbers are. A pipe operation requires a poll on the pipe fd which is a context switch. Apart from whatever internal processing tmux does, there are four extra context switches added for every keystroke + response.
Also, why have you done an “alacritty” vs “alacritty+tmux” benchmark yet have not done a “kitty+tmux” benchmark on this same table? That’s a big omission. The entire conversation is about the effects of adding a multiplexer on top of a terminal.
I chose the ASCII column because it's 99.999999% of what 99.9999% of developers see.
You’re arguing with a brick wall. The same people that demand performance-at-all-costs are the same people that copy-n-paste shit code around 30-40x, avoid any semblance of software engineering patterns, etc all because “performance”
Sure. Everything shouldn’t be an electron app, but there’s huge gray area for a balanced response. :eyeroll:
I think it's an unavoidable cost for any remote re-attachable system. No matter it's tmux/vnc/whatever remote protocol. But even in all these options. Tmux is still the lightest weight among them. Which can runs on a 500mb-memory vm totally fine. Spin up a actual desktop is way way more heavier than a terminal emulator like tmux. And allow you to split the terminal is just a free bonus tmux provided.
In an ideal world, connection can live forever, so re-attachable protocols like those are totally unnecessary. But in reality, the network sucks often.
It's nice that Kitty does most of what tmux does built in, but as the author points out, that's not really all that helpful for anyone who does any work over ssh.
And to me, bundling all that into a terminal emulator is bloat. Terminals should be terminals. If I want a multiplexer on top of that, I will... use a multiplexer on top of that.
I am potentially sympathetic to the idea that tmux and screen make it harder for terminal developers to add new features to their terminals. I don't really know enough about the issues involved to form an opinion. But from the perspective of a regular user, I do not want a multiplexer in my terminal app. When I need one, I prefer to reach for an app-agnostic multiplexer like tmux or screen.