I really disagree with the authors definition of minimal.
Terminal emulators have such a minimal user interface as it is it's a bit boggling that I have to make the case for the following "bloat" that other terminal emulators have.
I need scrollback because I do occasionally pick up my mouse and grab things that have scrolled off the screen. Tmux doesn't help with this but maybe there is some magic that I don't know these days.
I need tabs. At any given time many of those tabs might have instances of tmux somewhere in their multiply nested depths, generally on remote hosts.
I'm not going to start tmux on every local prompt just so I can use Alacritty and thus intentionally starting a tmux in tmux funshow.
I use "Monitor for Silence" "Monitor for Activity" pretty consistently.
It's free software so I glad the author is making something and hopefully enjoying the process. I can't really use this or consider it until he reconsiders. Maybe he'll get some collaborators that will argue him around on this.
> Features like ... are better provided by a terminal multiplexer
I would strongly argue that this thinking is putting the cart before the horse.
I don't use tmux, nor do I want to (though occasionally I have to use screen as a hack to keep programs running on remote servers, and I hate every second of it). Solutions like tmux arguably exist because terminals have poor UIs, and the terminal protocol is too weak to form the foundation for the kind of interactivity and statefulness provided by modern graphical UIs. If terminals were as powerful as, say, web browsers (not that I'm suggesting that anyone conflate them), the world would be a different, happier place.
I think Hyper [1] is going down the wrong path, but I strongly believe a new "terminal-oriented UI model/protocol" could be invented that would scratch every possible itch — good for text, mouse support, custom UI widgets, seamless remote connections, multiple screen regions — without sacrificing functionality at all.
There's been a lot more pushback on the scrolling decision than I had anticipated. It's not something I want in my terminal, but it seems that a simple feature like this is essential for others. Perhaps I should reconsider.
I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern. At least if we were to add support, it could be designed as a build feature and be removed completely if it were undesired.
Scrollback support was added to AmigaOS ca. 1987 (with 2.04), and enabled on machines with 512KB RAM and a 7.xx MHz M68k CPU... Performance was not a problem then. Of course the highest resolution most people would run it on would be 640x512 back then, with typically 2 bit planes. But data volume has grown much less than CPU speed and memory bandwidth.
Incidentally, AmigaOS' terminal design is worth exploring - it is a fascinating example of layering. And the AROS re-implementation, while not very clean, is also partially object oriented (in C; disclaimer: I wrote part of it) in how it layers the console units from the simplest to most complete (cut and paste support + scrollback). Even back in the 80's performance was good enough for this that AmigaOS started using dispatch-function based OO all over the place, and the AROS re-implementation of the console code uses that method, which is not at all the fastest way of doing it, but it's fast enough even on real M68k's.
Any modern PC is going to be at a minimum several hundred times faster.
All you need is to maintain a linked list of lines, and add code to free or reuse when you reach the maximum size of the scrollback buffer. If you want you can easily also just use a ring-buffer and wrap around if you want to set a size limit in bytes instead of lines, and just maintain indexes into it. It's trivial to do this in ways that doesn't cause performance issues.
The developers of the VTE widget had a problem a few years ago. The widget was using 16 open file descriptors per terminal emulation instance. This was causing problems for terminal emulator programs that had the architecture of a central server process that does all of the terminals on multiple X displays.
A GUI terminal emulator for such an architecture needs at least two open file descriptors, one for the connection to the X server and one for the master side of the pseudo-terminal. The other 14, it turned out, were being used by VTE's scrollback buffer mechanism, which involves writing data that have scrolled off the top of the screen out to (temporary) files.
They had managed to reduce this, by rearranging the structures of the scrollback files, to 8 open file descriptors per emulation by 2011, and reportedly it will be soon down to 4.
Interesting tidbit #1:
It was mentioned elsewhere in this discussion that the alternate screen on many terminal emulators has no scrollback. This is because the programs that switch between primary and alternate screens aren't actually doing that as far as they are concerned. They are switching between scrolling mode and cursor addressing mode (see http://superuser.com/a/715563/38062 for details), the latter not really having the concept of a negative row coördinate.
The VTE widget was using twice the number of open file descriptors, because both scrolling and cursor addressing modes had scrollback files.
LXTerminal has this single centralized emulator process architecture, too. It has a rather nasty open file descriptor leak with which one can render LXTerminal completely unusable in about 1 minute (if one has an open file descriptor limit of 1024).
I've already tested alacrity and it's super easy to configure, the only thing stopping me from making the move is scrollback. I understand not adding tabs or a GUI config: I use my WM to do tabbing on linux even though my terminal implements tabs. However scrollback is an absolute must for me. If you implemented scrollback I would be able to switch terminals from terminology (at first glance).
I use tmux a lot, but I don't use it for every session. To me, forcing me to use tmux to get scrollback is precisely violating the idea of 'one tool doing one thing'. You're forcing me to compose a Swiss army knife (tmux) into situations where all I need is a knife (a terminal that works well with the idioms of my environment).
I don't need tabs (I use i3wm), I don't need splits or session management (when I need that I use tmux). But I do often need to scroll back on a temporary session when I didn't plan for it in advance. I open a lot of terminals. They're never all going to be tmuxed.
I respectfully disagree. Alacritty follows the Unix philosophy of doing one thing, and doing it well. I used to think that terminal scrollback and tabs were great ideas -- but switching to tmux changed my mind completely. Tmux is so much more capable for managing your session history. The terminal's tab and scrollback features can never match this. They're just bloat :p
> I respectfully disagree. Alacritty follows the Unix philosophy of doing one thing, and doing it well. I used to think that terminal scrollback and tabs were great ideas -- but switching to tmux changed my mind completely. Tmux is so much more capable for managing your session history. The terminal's tab and scrollback features can never match this. They're just bloat :p
This is the problem of Unix philosophy, because it applies differently for different people.
For example, I use i3, that is a tilling window manager, so I don't need tabs or split management for tmux. Actually, I removed tmux since I started to use i3 because using i3 features feels much more natural, since they apply to every window. However, there is only one thing that I can't have with i3 that is scrollback buffer, so while I don't need a terminal with tabs, I need support for scrollback buffer. Adding tmux just to get scrollback goes against Unix philosophy.
> Adding tmux just to get scrollback goes against Unix philosophy.
I agree. Rather than adding scrollback support to allacritty, maybe someone could write an independent program for scrollback support (a la dtach/abduco for detaching/reattaching)?
Such a program would be useful for all terminals which lack scrollback (alacritty, st, possibly others).
For the record I use st with dtach and dvtm; scrollback is supplied by dvtm, but it would be nice to decouple it some more.
100% agree, to the best of my knowledge there exists no tool that adds scrollback support to a terminal emulator without doing anything else. My solution now is to use tmux for this, but it is not really elegant. Piping everything through less is not an option :P
If you want decoupling, look at the AmigaOS design: The console (terminal) consists of a bunch of independent elements:
- Device drivers feeds raw input to input-handler
- console.device manages a single console window. it receives raw input from the windows message port (courtesy of the input-handler) and "cooks" it into escaped character streams (which can include things like mouse reporting), and processes simple output that it translates into window output.
- console-handler receives the escape codes and interprets more complex sequences before passing the result on to the application that has the console open, and writes output back to the console.device.
Most of this would run in separate threads.
This lets any application open special filenames like "CON:" to open a console window.
Within console-handler, multiple different "units" are layered - in AROS (AmigaOS compatible open source), the basic (no copy and paste, no reflow, no scrollback) unit, the unit with copy and past and reflow, and the unit with above and scrollback, are layered on top of each other via inheritance, using a system-wide OO system modelld after Commodores old BOOPSI (basically a simple vtable based approach with a "catch-all" method dispatch entrypoint for user-added methods; it's not fast with deep inheritance hierarchies, but it's fast enough for this kind of use).
The copy and paste itself is implemented via a separate tool - ConClip - started on boot (and optional; if you don't start it you simply don't have cut and paste), which receives messages about what to cut and paste and writes it to the "clipboard.device", which by default writes each cut/copied piece of data to the CLIPS: volume as IFF formatted files, which by default maps to a directory in a ram-disk, but which can be re-mapped elsehwere. This all happens asynchronously, to accommodate cases where people e.g. remapped CLIPS: to a floppy and had to swap it in (rare, but possible if you had to deal with low memory situations).
This is something that frustrates me to date with Linux etc. - AmigaOS was far more decoupled, with clear, well-documented boundaries for people to hack on (e.g. several people wrote alternative console-handlers and console.device's that you could totally replace the original with to the point that any application that used terminal windows could be made to use your preferred console device. Even third party components tended to follow this approach (e.g. compression in AmigaOS is usually done via the XPK suite of libraries, which provided a third party API for opening compressed data streams, that let you plug in any compression algorithm as a library - as a result most apps in an Amiga system that supports compression can support most compression algorithms you drop in a system-wide library for).
Thanks, that's really interesting. I grew up with Amigas exclusively until getting a family PC around 2000, although I didn't tend to use the CLI or do any programming back then.
I'm aware of BOOPSI, and the datatypes system which sounds similar to what you describe.
One problem on AmigaOS was(/is?) the lack of packaging and dependencies, e.g. installing many programs on a fresh copy of Workbench won't work, due to missing libraries, etc. Thankfully that's easier to manage these days by scouring Google and Aminet, but it's still manual.
Interestingly, I've found Amigas to become more stable over time, unlike e.g. Windows where some people recommend formatting every year or so to remove cruft. The more stuff you install in Workbench, the more libraries, etc. you accumulate, so the fewer problems you encounter trying to install/use other things. I'm not sure if this is a consequence of the OS design, or from developers bending over backwards to avoid problems (e.g. conflicting names, etc.)
Yes, BOOPSI was the model for the OOP used in AROS.
> One problem on AmigaOS was(/is?)
Is, sort-of. Package managers didn't enter the scene until much later, but Commodore did release Installer, which while not a package manager provides a s-expression based mechanism for describing installation flow.
It's alleviated because Amiga libraries tends to very strictly insist on backwards compatibility, so you should generally be able to drop a newer version of a library over an older version and things will keep working (and the libraries and all compliant binaries contains version numbers).
But of course the community today is very small, and was smallish originally too, and so it's gotten easier and easier to deal with.
If there was to be a resurgence (there is new hardware but it's expensive niche PPC hardware; AROS runs on pretty much "anything", but is incomplete), it'd need a lot of big overhauls - in particular memory protection (some work is ongoing but it's hard due to AmigaOS APIs relying a lot on pointer passing) and SMP, but also lots of tooling we take for granted today like package management.
I'm not holding my breath for that, but I do wish more AmigaOS ideas will get picked up elsewhere. Linux still feels like a hodge-podge in comparison.
I use i3 too, but it doesn't replace tmux or screen for me for a simple reason: I can't maintain state for a remote server as i3 windows. My screen session outlive my laptop uptime by years. And easy API to let a remote terminal management tool create child windows/tabs would be fantastic...
When I need state in remote servers, of course I still use Tmux. I was referring to local Tmux sessions, that I mostly used for tabs/splits before I started to use i3.
> Alacritty follows the Unix philosophy of doing one thing, and doing it well.
That principle is often misapplied, and I think that's true here, too.
The "do one thing" about Unix is really about composability (e.g. "find" doesn't need to sort because you do "find | sort"), but you don't compose a terminal app with anything.
A terminal app that has terminal features doesn't violate any principles of simplicity.
That particular example of find not needing to sort persistently annoys me. sort doesn't know anything about the structure of its input, so it has to read and buffer all of it before it can sort it. find knows that its input is a tree of strings, which it could exploit to produce sorted output at the cost of buffering one directory's worth of filenames at each level of the tree.
It's rarely a significant problem in practice, but it annoys me in principle!
To avoid cluttering "find" with a sorting interface, we could use the modern technique processing push-down:
If you do "blah | sort", then "sort" could ask its upstream processing node whether it supported sorting on the requisite fields, and "push down" the necessary sort-order descriptor into the "blah" step.
That requires two things: That the pipe API sets up a communications channel between the two programs in a way that makes them aware of each other and able to exchange information; and secondly, that the pipe protocol is based on typed, structured data. I want both things.
Imagine if you had that, then you could conceivably also do:
and psql would automagically rewrite its query to:
select firstname, lastname from foo order by lastname
That's the future I want to live in, anyway.
The inability to do this sort of thing really a product of a failure to modernize the 1970s text-oriented pipe data model. I believe PowerShell (which I've never used, only read about) provides a mechanism to accomplish this sort of thing, at the expense of being extremely Microsoft-flavoured.
I don't think there's anything even vaguely scifi about those abilities, but the Unix world is hampered by a curious reticence to innovate certain core technologies such as, well, Unix itself. That's why we still have tmux and such.
... or the downstream program could ask the upstream one (or get automatically along with the stream) about meta-data/type information for the stream it is being passed, and then it could benefit fully from already-known information. Though that does not solve the need to potentially read the full stream and buffer it before doing the processing.
I use st as my terminal application. Inside, I run dtach to provide detaching/reattaching functionality. Inside that I run dvtm to provide multiplexing and scrollback. Inside that I run bash. Inside that I run ad hoc commands.
Everything's highly composable, e.g. I can switch out bash for zsh, fish, etc. I can switch out dtach for abduco. I can switch out dvtm for tmux or screen. I can switch out st for xterm or urxvt. And so on.
Adding an extra layer for scrollback, separate from a multiplexer, wouldn't disrupt anything, and would provide more flexibility for composition.
Each to his own. Your setup sounds like a parody of the most outlandishly neckbeardy things devs can do in a shell. Most users don't want to deal with that sort of "layering".
> Your setup sounds like a parody of the most outlandishly neckbeardy things devs can do in a shell.
I shaved off my neckbeard, I'll have you know! ;)
My setup's no more outlandish than using tmux or screen, except instead of typing `tmux` or `screen` I type `shell`, which aliases a `dtach dvtm` one-liner (with a few options sprinkled around, so I don't have to bother with config files).
The point is that none of these applications care if/how they're composed; if I want to add in or swap out something, it's just a change that one-liner.
Not so if, say, my terminal application were hard-coded to rely on tmux, as some sibling comments have suggested.
As I pointed out elsewhere, in AmigaOS you actually did often compose the terminal/console handler with other software... The reason we don't in Unix-y systems is that we've gotten used to terminals implemented as standalone applications rather than as reusable components that integrate well with other things.
In AmigaOS it was fairly common for applications to reuse the standard console handler - the same one used for the shell - to provide a custom console or even editor windows etc.. For minimal integration all it takes is to read from/write to a filehandle.
That said, though as I noted elsewhere, even AmigaOS got scrollback in the console handler by '87 - the extra code measures a few KB; it'd be more hassle than it was worth to split it out.
> A terminal app that has terminal features doesn't violate any principles of simplicity.
It still depends how these features are implemented.
For example in dvtm scroll back history is made searchable by piping it to $PAGER. Similarly, copy mode is implemented by using $EDITOR as an interactive filter.
This wasn't a feature of the original VTE videoterminals these apps are emulating though. I'm pretty pro-scrollback, but I have to say the way its been implemented so far has frankly not been very principled.
Well, the difference all comes down to how one views tmux, and I'm on the side of hating it. I personally use tmux only to background applications, and any of its other features are "bloat" to me.
After reading everyone praising tmux, tmux, tmux, I tried to use it several times, several days or weeks each time. The thing only got in my way all the time, to the point that now I prefer to lose sessions than to use tmux. It has to be a really important and peculiar and heavy operation, to have me still launch tmux punctually.
Not your parent, but here's my take. For remote usage, tmux doesn't provide much beyond vanity over screen, and is less likely to be installed on a shared host. Locally, I generally get by with &, bg, fg, and Ctrl-Z if I absolutely can't open another TTY, and a tiling window manager (or Emacs) provides a superior tiled workflow for the applications I use.
There are some cases where tmux could help me, but my X session and terminal emulators are stable enough where I'm not worried about them crashing and interrupting my shell session. As such, I have no need for tmux, and using it just for terminal emulator scrollback seems hamfisted.
The only use case I can think of is running large distribution updates which might potentially pull the rug out from under your graphical session, but I tend to run those on a non-X terminal if they look sketchy.
Edit: I'd totally consider using tmux as an alternative to X on my Raspberry Pi, but if I have X/Wayland, It doesn't offer me much.
It's not cheating if you gain those features back by using a separate program (tmux) and still see a performance improvement over all other tools, which is what the author is implying. All that does is suggest that terminals might not be the proper layer at which to implement those features (and for the record, I'm on the side of having scrollback, but the lack of it isn't a dealbreaker).
I'd be very happy if you more closely integrated with tmux and used the features from tmux instead transparently. I don't care how the terminal does scrollback, as long as it does. If you forwarded the scrolling commands to tmux then great. Same thing with tabs, panes etc.
As much as I like tmux (although I exclusively use it via byobu), the single most annoying thing is that it won't let different viewers see different content. (eg start two terminal emulators, run tmux in both and any switching you do in one affects the other. There are supposedly elaborate workarounds, but far too much effort.)
In Byobu, you simply need to create a new session. Ctrl-Alt-F2. Then Alt-Up/Alt-Down to move among sessions. Each user can have their own session easily like this! Shift-F1 for the hotkeys, if you need a reminder ;-)
Ctrl-ALT-F2 would take a miracle to work. Shift does as you describe, but the net effect is still nowhere what is intended.
Also note I am the same user. The functionality I want is how byobu behaves with screen. eg you can start 3 xterms, in each one run byobu. And each one can jump around as they see fit all sharing the same screen session. No work, no fuss and exactly sane.
The tmux behaviour baffles me. I can't understand why anyone would want all their viewers to change in sync. Short of a classroom demo environment, it really doesn't make sense as a default.
I'd be delighted if by default byobu did whatever was needed to make tmux behave usefully.
Interesting... Frankly, I love the tmux default, to sharing the window, while also supporting the concept of "sessions". The shared view makes paired programming with a colleague across the world, while on the phone or a video conference super easy. Different users start in the same "session", and share the view of "windows" and "panes (aka splits)". If they want separate views/control, then they start separate sessions.
For your usecase I can understand. But when it is the same user using defaults it makes absolutely no sense. Why would they want separate xterms on the same display to be in lockstep by default?
Am I the only one who runs more than one terminal at a time? What happens now is I start an xterm on monitor #1 and start byobu within that. Various windows (whatever you switch amongst on pressing F3 and F4) are started - eg one might be client code running, one might be server code, one might be a database server etc. But sometimes for example I want to look at the client code output and server output simultaneously. At that point I switch byobu to the client window, and start a new terminal on monitor #2 and tail logs or whatever is appropriate. It is an annoying pain that I can't just run byobu and switch as I see fit.
In any event this is a multi-year frustration for me. People keep coming with convoluted workarounds (pointing tmux to tmux as far as I can tell) which it then isn't possible to figure out how to apply to byobu. All the while I wonder why two xterms running next to each other would ever want to be in lockstep by default?
A concrete example of what I mean. The user starts 3 xterms each running byobu with no additional parameters:
for i in 1 2 3 ; do xterm -e byobu & ; done
Why would they want the view in each xterm to be identical, and why would they want changing the window (is that right terminology? pressing F3 and F4) in one xterm cause the other two to change in lockstep?
Ok, now make byobu do that since it is how I actually use tmux. Also make sure it happens on every system I use. This gets tedious and annoying very fast. Heck mouse support not being on by default, requiring a single line in a config file on every system is already annoying enough.
The problem isn't that it is possible in theory. It is annoying in practise, unless you only have one machine and only need to do all this once in one system.
> There's been a lot more pushback on the scrolling decision than I had anticipated.
Even if tmux is in theory a better solution, it's not such a radically better solution that the benefits outweigh the switching cost. Terminals with scrollback have been around at least 30 years at this point [1], and scrollback is by far the majority use mode. You're asking 95%+ of your potential userbase to spend a bunch of time retraining themselves for little or no benefit.
Scrolling down and back is a key part of the web user experience. Even if every terminal emulator got rid of scrollback, most of your users would still have scrolling back baked into their brains. When they want to see something that just scrolled past, they are going to do what they do in a web browser, which is to look for a scroll bar, hit a scrolling key, or perform a scrolling gesture.
That's not to say you shouldn't try radical things. But if you want user adoption, you have to make sure the benefits you offer are very much larger than the costs you impose. So radically different UI can't be about as good as the existing one; it has to be radically better.
[1] And of course terminals are made to emulate teletype machines, which had infinite scrollback to begin with.
Scroll back is the only feature missing that would block me, assuming you permit changing the colour mappings.
I generally run five or six desktop terminals, only one of which is running screen locally. I more normally run something like screen to get persistence across suspends on an SSH connection. I usually don't do much side by side stuff in terminal so tmux isn't a big win for me. Also tmux didn't run on cygwin for the longest time, and I expect the same experience on all my platforms.
However the big tmux users in my life would still use it as is.
I am the one with you. If you decide to add scrollbar later, please at least make it optional.
I am using firefox with pentadactyl, and the firefox is configured as a minimal terminal like st. Basically, firefox becomes my GUI terminal. But what I want is a much lighter weight GUI terminal than firefox.
I am using three terminals, st for regular use. mlterm for its image support (sixel). and firefox for heavy-GUI needs. Alacrity seems perfect to replace st now.
> I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern.
Just do it. I doubt it will be hard to beat tmux performance, in my experience it's slow like molasses and I only use it if I must - remote persistency, screen sharing, etc.
I love tmux since I regularly move between OSX and linux machines across several versions. With tmux I can create one .tmux.conf file that standardizes my tab/split behavior across all of the systems regardless of the emulator I use. This works a lot better for me than having to install specific emulators on each machine, several of which I do not have administrative rights over.
> I don't use tmux, nor do I want to (though occasionally I have to use screen as a hack to keep programs running on remote servers, and I hate every second of it). Solutions like tmux arguably exist because terminals have poor UIs, and the terminal protocol is too weak to form the foundation for the kind of interactivity and statefulness provided by modern graphical UIs. If terminals were as powerful as, say, web browsers (not that I'm suggesting that anyone conflate them), the world would be a different, happier place.
I have the opposite impression. I actually anjoy time spent in my tmux + vim setup while I hate the time spent in a web browser. Web browsers seem bloated to me and I always feel like I'm forced to use the mouse too much while using them. I've heard about vimperator, but every time I've tried it seemed poorly integrated (the authors did an incredible job nonetheless).
The only drawback of delegating scrolling to tmux that I see is that my experience running tmux locally and using ssh to use a remote machine with another (remote) tmux session wasn't great. Keyboard shortcuts were usually caught by the local machine and not by the remote one. So I just don't run tmux locally when I want to ssh into a remote machine. Problem solved more or less.
> Solutions like tmux arguably exist because terminals have poor UIs
Whilst I totally agree with you, I think Tmux is a lot like vim in its power. Along the same note, I'd wager a gTmux, much like gVim would be q real nice way to multiplex terminals when we get the UI to beat the TUI.
I mean Terminator is basically gTmux, right? They aren't quite the same: tmux is a terminal multiplexer, Terminator is a terminal emulator with tabs and panes. Both approaches have benefits and drawbacks.
If you want keyboard only, I don't think GUIs can beat TUIs. But yeah, there's a learning curve.
The problem with GUIs is a very display-session centric view. tmux/vim work fine over SSH, Terminator/gVim don't. With tmux, your sessions are separate from your terminal instance. If your X session crashes, depending on how you started tmux, you just have to relaunch a terminal and reconnect to tmux. This is pretty invaluable. So this separation is powerful, and IMO very Unix-y.
The multiplexer v emulator is the key difference. At least for me. Exactly because of the ssh and session persistence you mean.
For the thing to replace the TUI, I'd expect something in between current terminals and X11. With the simple, limited (and thus easily remotable) data of the current terminal emulators, but with much more drawing capabilites than the current grid-limited ascii art.
I came to this idea when trying to get vim up to a full IDE. Trying to get even half of netbeans' interface into vim just takes so much space in the ascii grid. And anything dynamic moves half the screen a shitton.
Ok, so you're interactively using a program on a remote server and you don't want it to die if you lose your connection? Screen isn't a hack in that case :)
It presumably doesn't feel like a hack to you because you're used to this mindset.
To me, it's a deficiency in the lack of session management for SSH. All that SSH gives me is a two-way pipe to the other server's I/O. That's simple and elegant, but why does it create a new pipe every time? It's connection-oriented, which is a concept that hasn't seen any innovation since the 1970s.
My preferred innovation here would be a local shell that had remote access. Rather than pipe I/O to the remote shell, give me a local shell which happens to execute its verbs on the remote machine, and let the remote file system simply be a volume. All my session state (including command history) can be local, there's no need to keep that on the remote host. A remote host is just another context.
I believe Plan 9 tried something similar, but very few people have picked up on its innovations.
~ $ cd /ssh:tol-eressea:.
/ssh:tol-eressea:/home/db48x $ ls
db48x.net libvirt-sandbox rpmbuild zone.sh zone.sh~ zone.txt zone.txt~
If you've set ssh up to use control sockets then it can reuse existing connections.
MOSH is also nice; it decouples the program you're running from your connection, just like screen does, and it also uses udp instead of tcp so that it doesn't have to worry about dropped connections. Even your client's ip address can change and everything keeps working.
> Features like GUI-based configuration, tabs and scrollback are unnecessary. The latter features are better provided by a terminal multiplexer like tmux.
This seems kind of like saying "everyone should use their computer the same way I do". I don't use tmux; maybe I should learn to use it. However, I seem to be getting along fine without it, and no scroll back is a deal-breaker for me.
That said, this is still a cool project and I wish them success.
> This seems kind of like saying "everyone should use their computer the same way I do".
People do have that attitude from time to time, in this case i'd phrase it more like "no one seems to use their computer the way i want to, so i wrote some software"
Firstly you insinuate that the author is requiring people to interact as they do - this evidently is not the case, a suggestion has even been made on one of many ways to behave differently.
Secondly the "I seem to be getting along fine without it" statement pointlessly hampers progress. There is no basis or reasoning for this, instead there is a decision - whimsical by the looks of it - to not use it. You could say that you don't anticipate the gains of the system to be worth the transition cost, or you could actually try it and have some useful criticism, or any number of other things.
Thirdly, the linked page doesn't ever mention the 'minimal' your parent introduces. Minimal implies sufficiency (least sufficient, but sufficient none the less), the Alacritty page states simple - which does not.
I find the final comment hilarious. You have just denounced a tool based on an implementation triviality (which can be easily bypassed) and choose to summarise with a statement as undoubtedly false as it is trite. Did you read the page?
I think it's a cool project, but I personally wouldn't use it because it lacks a feature I expect terminal emulators to have and am not motivated to change how I use my computer. Other people may be happy with this program. If someone implements the feature I want some day, then I might use it as well.
I'm sorry if I came across as overly critical of the project, that wasn't my intent. I just think they're limiting their audience by assuming that a feature that isn't important to the developers is unimportant to users because a workaround exists that the developers are satisfied with. People really don't like to change how they do things, regardless of whether the way they're doing them now is "the right way" or "the best way". Maybe they're making the right decision and everyone really should be using tmux, and if so, great, they'll have have a community of happy users. If their target audience is someone other than me, I'm okay with that.
Moreover, tmux does its own output parsing, so when you do your `cat 1gb_file.txt` inside tmux inside a terminal, you have two layers of output parsing happening. I can't see how that doesn't impact the performance that is claimed for Alacritty. But perhaps tmux is really fast.
I wouldn't trust a third party application to be part of the performance experience I'm claiming for my own application, though.
Couldn't you say that about SSH? If your application is taking forever reading from the stdout buffer, your application will block when it is trying to write to stdout with say, printf, or fprintf.
tmux does provide full scrollback with mousewheel support too.
# Enable mouse support including scrolling
set -g mouse on
# Versions prior to 2.1 may want this too:
set -g mouse-utf8 on
history-limit 5000 # 5000 lines of history per pane. Adjust as needed.
It's not as good as native scrollback though. For example, by default, as soon as you select something in tmux, the selection goes away, and you have to hit a tmux-specific keybinding to paste it back into the terminal. That's never what I want! If I'm selecting something it's probably because I'm going to copy it to my system keyboard. I think you can disable this part, except of course what you're left with at that point is a tmux selection, which is NOT a terminal selection, meaning you still can't copy it to your system clipboard.
Also, scrolling is somewhat unreliable, although I still haven't figured out why.
In any case, I use tmux in some of my terminal tabs, and very frequently I have to hit ⌘R to disable terminal mouse support just so I can select & copy something without tmux interfering (I could also hold down the Fn key, except I use an external Das Keyboard, and the Das Keyboard folks still haven't figured out that their Fn key should actually behave like Apple's Fn key and let the system know when it's pressed by itself, as opposed to what it does now which is simply modifying the keypress events for other keys without sending any independent event for the Fn key).
Apple's Fn key isn't ideal. The USB HID usage ID is not one from the keyboard or consumer key pages. It's in one of the "vendor defined" pages, meaning that every keyboard driver supporting has to specifically recognize the device vendor and model, because without that context one cannot know what a vendor-defined ID means, and every new keyboard supporting this requires an operating system device driver update across many operating systems as well as system firmware updates to machines whose firmwares recognize this vendor-defined ID as a keyboard key, all to add another vendor ID in to the drivers' lists of "this vendor+device has Apple's Fn key".
Still, Das Keyboard has been making a Mac-specific keyboard for many years now, you'd think they'd at least reach out to Apple to see if they can get their keyboard recognized as having a Fn key (or, alternatively, provide a kext that adds support themselves). But the one time I asked them about it, they didn't seem to even care about how the Fn key behaves, so I doubt they've even made an attempt.
that as the case may be, the same argument applies to vim (i use vim, with at least some of its keyboard shortcut glory, and love it); it might be faster in a lot of cases, but at the end of the day editors like sublime, atom, brackets, etc all have a much larger user base because people aren't willing to learn
No, they're criticising tmux as a proffered alternative to a full-featured terminal emulator, which is often used by non-power user programmers who are not willing to learn (like me).
I switched to tmux a few years ago and never looked back. What is your problem with mouse? I have quite basic tmux config, very basic terminal emulator (st) and enjoy mouse scrolling even in nested tmux scenarios. Selection is done with vim keybindings which is much faster than mouse especially if you scroll and look for something visually.
I can relate to your feelings. In the beginning I was _very_ skeptical about running tmux locally. But very quickly I reconfigured tmux as I felt and stopped noticing at all if I work locally or remotely. Everything is very smooth and pleasant since then.
The only bad thing I remember: default tmux keybindings suck. I just redefined almost everything.
> The only bad thing I remember: default tmux keybindings suck. I just redefined almost everything.
It's true, e.g. ^B / Ctrl+B is a terrible prefix. All of this just makes tmux harder to learn, and less portable/transferrable. But I think there's value in having to feel out the ideal configuration for your workflow - but the prefix is still inexcusable.
Are y'all on Linux/xterm or something? I've had trouble getting this to work in OSX with the default terminal. At one point I got it to partially work by installing some scary looking plugins, but it broke other mouse behavior for me (copy/paste I think).
I'm on OSX and mouse-support. vim bindings, clipboard, and extended scrollback in tmux "Just Works™" in both Terminal.app and iTerm2. The only external software that I had to install separately is reattach-to-user-namespace to get the clipboard working.
The only problem I encountered was really bad kernel panics when the tmux server exits (i.e. last session is closed), but it has been fixed as of tmux 2.1 as far as I can tell.
I'd say give it another try; the problems you were having might no longer be an issue now.
I never managed to actually like tmux. It breaks too much of what I'm used to, like mouse wheel scrolling, Ctrl-arrows, ESC in Vim and a lot of other small things.
The ESC thing is fixable by configuration, at least, but I really doubt I can make tmux behave like my native terminal.
I'm not quite sure what you expect Ctrl-arrows to do, but I'd be surprised if tmux can't be made to keep that behaviour.
If you spend a lot of time in the terminal, there's a lot of value to be gained from using tmux. It takes some configuration to get value from it, but there is value there.
tmux has copy-mode (^B : copy-mode <enter>) which lets you scroll through history and copy out snippets without using the mouse. There are also some tips out there for nested tmux sessions.
For what it's worth, I use tmux just like the author of this project: a single urxvt terminal with tmux running inside (no scrollbars, tabs, menubars, etc) and it works for me.
At some point, every application (browser, terminal, tmux, ...) re-implementing their own version of tabs is kind of silly.
Ideally "look at 'window' X of application Y" (where window == window / terminal tab / tmux pane / whatever) is what the local window manager should be used for.
E.g. instead of 1 tmux session with 4 tabs in it (or 1 terminal window with 4 tabs in it), I will run 4 mosh/tmux sessions (or 4 terminal windows) with 1 tab each, and use my regular window manager commands (i3) to switch between them.
In theory this is a better separation of concerns, and I can have one set of key bindings to do all window switching. Not:
1. Use window manager keys ctrl-foo to get to the right desktop/terminal window
2. Use terminal keys ctrl-bar to get to the right terminal tab with my tmux session in it
3. Use tmux keys ctrl-zaz to get to the right tmux pane
(Obviously a contrived example.)
...that said, I still use a crap load of tabs in Chrome, so theory != practice.
I avoid tmux and screen to. Instead I use SSH multiplexing (great for rsync tab complete too), and let the window manager so its job.
All I need is an orthogonal solution for persistent shells (how about I persist arbitrary login process trees, graphical or textual, OK?) And I'll truly have no need for tmux.
Then again I don't ssh too often for too long, so the last part is endlessly low priority.
Surprised people consider tabs and scrollback similarly basic features. As someone using only basic linux terminal emulators like x/u/aterm or urxvt its interesting to see that people consider tabs a basic feature, while I don't know a single term without some scrollback.
Really makes you realize how different people's expectations are.
yeah, it's less "unnecessary", more "provided elsewhere". in this case, he's saying by tmux... which does mean learning a bunch of new keybinds, which is a little upsetting
Terminal emulators have such a minimal user interface as it is it's a bit boggling that I have to make the case for the following "bloat" that other terminal emulators have.
I need scrollback because I do occasionally pick up my mouse and grab things that have scrolled off the screen. Tmux doesn't help with this but maybe there is some magic that I don't know these days.
I need tabs. At any given time many of those tabs might have instances of tmux somewhere in their multiply nested depths, generally on remote hosts.
I'm not going to start tmux on every local prompt just so I can use Alacritty and thus intentionally starting a tmux in tmux funshow.
I use "Monitor for Silence" "Monitor for Activity" pretty consistently.
It's free software so I glad the author is making something and hopefully enjoying the process. I can't really use this or consider it until he reconsiders. Maybe he'll get some collaborators that will argue him around on this.
Cool project otherwise.