6 ms·

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 termin

• 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.
      • arandomcoder 10y ago
        Ah, but you do compose it -- with tmux, for instance :-)
        • netheril96 10y ago
          The composition is very different from the integrated case. Alacritty with tmux is wildly different from Terminal.app.
      • lisivka 10y ago
        PuTTY does lot of things. PuTTY is good solution for world of Windows, but alien in world of UNIX. "Do one thing" rule applies to terminals too.
      • twic 10y ago
        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!
        • atombender 10y ago
          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: psql -c "select firstname, lastname from foo" | sort -f lastname 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.
    • netheril96 10y ago
      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.
      • kibwen 10y ago
        I've honestly never seen anything but love for tmux, can you explain why you hate it?
        • uabstraction 10y ago
          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.
        • ori_b 10y ago
          Personally, I don't hate it. It just doesn't do anything for me -- I can just open a new terminal if I want another split.
      • wott 10y ago
        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.
    • euyyn 10y ago
      Can you go into details about tmux vs tabs & a scrollbar?
    • m45t3r 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 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.
      • chriswarbo 10y ago
        > 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.
        • vidarh 10y ago
          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).
  • kibwen 10y ago
    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).
• rogerbinns 10y ago
  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.)
  • jcelliott 10y ago
    You probably want to do something like this: tmux new-session -t main -s main2 In practice it looks the same as attaching to the same session twice, except you can look at different windows at the same time.
    • rogerbinns 10y ago
      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.
  • dustinkirkland 10y ago
    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 ;-)
    • rogerbinns 10y ago
      What would you know about byobu :-) 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.
• qb45 10y ago
  > 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.
• RX14 10y ago
  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).
  • compuguy 10y ago
    Honestly, I don't like tabbing terminal instances.
• vidarh 10y ago
  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.
  • JdeBP 10y ago
    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 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. * https://bugzilla.redhat.com/show_bug.cgi?id=667539 https://bugzilla.redhat.com/show_bug.cgi?id=667539 * https://bugzilla.gnome.org/show_bug.cgi?id=646098 https://bugzilla.gnome.org/show_bug.cgi?id=646098 * https://bugzilla.gnome.org/show_bug.cgi?id=738601 https://bugzilla.gnome.org/show_bug.cgi?id=738601 * https://bugzilla.gnome.org/show_bug.cgi?id=741520 https://bugzilla.gnome.org/show_bug.cgi?id=741520 Interesting tidbit #2: 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). * http://unix.stackexchange.com/a/333578/5132 http://unix.stackexchange.com/a/333578/5132
• stormbrew 10y ago
  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.
• barrkel 10y ago
  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.
• guilloche 10y ago
  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. Thanks for good work.
• wpietri 10y ago
  > 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. You're also up against a variant of Jakob's law: https://www.nngroup.com/articles/end-of-web-design/ https://www.nngroup.com/articles/end-of-web-design/ 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.