10 ms·

> 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

> 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. [1] https://hyper.is https://hyper.is

db48x 10y ago
Have you heard of nohup?
- lobster_johnson 10y ago
  Sure. But nohup doesn't work for shells or anything interactive. You can't attach to it.
  - smegger001 10y ago
    or you could type CTRL+Z BG
    - netheril96 10y ago
      And that will still send the program SIGUP, killing it when you close the terminal or lose your ssh session.
      - dbaupp 10y ago
        You can do that (or spawn in the background from the start, with &) while also using nohup.
    - qb45 10y ago
      Still can't reattach after logout/reconnect, which is a very common screen/tmux use case.
  - db48x 10y ago
    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 :) Although you could ditch it and use MOSH instead.
    - lobster_johnson 10y ago
      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.
      - db48x 10y ago
        Maybe you want eshell then: ~ $ 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.
jwilm 10y ago
Thank you for the thoughtful comment. 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.
- netheril96 10y ago
  > Performance with large amounts of output is also a concern. Frankly, removing two very important features for a lot of people (me included) and then claiming highest performance feels a bit like cheating.
  - arandomcoder 10y ago
    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
    - lobster_johnson 10y ago
      > 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.
      - tatterdemalion 10y ago
        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.
rocqua 10y ago
> 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.
- guitarbill 10y ago
  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.
  - rocqua 10y ago
    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.
joshuata 10y ago
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.
yakubin 10y ago
> 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.

db48x 10y ago

Have you heard of nohup?

lobster_johnson 10y ago
Sure. But nohup doesn't work for shells or anything interactive. You can't attach to it.
- smegger001 10y ago
  or you could type CTRL+Z BG
  - netheril96 10y ago
    And that will still send the program SIGUP, killing it when you close the terminal or lose your ssh session.
    - dbaupp 10y ago
      You can do that (or spawn in the background from the start, with &) while also using nohup.
  - qb45 10y ago
    Still can't reattach after logout/reconnect, which is a very common screen/tmux use case.
- db48x 10y ago
  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 :) Although you could ditch it and use MOSH instead.
  - lobster_johnson 10y ago
    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.
    - db48x 10y ago
      Maybe you want eshell then: ~ $ 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.

jwilm 10y ago

Thank you for the thoughtful comment. 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.

netheril96 10y ago
> Performance with large amounts of output is also a concern. Frankly, removing two very important features for a lot of people (me included) and then claiming highest performance feels a bit like cheating.
- arandomcoder 10y ago
  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
  - lobster_johnson 10y ago
    > 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.
    - tatterdemalion 10y ago
      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.

rocqua 10y ago

> 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.

guitarbill 10y ago
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.
- rocqua 10y ago
  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.

joshuata 10y ago

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.

yakubin 10y ago

> 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.