15 ms·

Contour: Modern and fast terminal emulator

181 points by ingve 3y ago

kelsey9876543 3y ago
i don't see the point of adding vi input mode to the emulator when we have it inside bash with `set -o vi`
- Gualdrapo 3y ago
  As it supports Windows, I guess it would be useful for them
  - kelsey9876543 3y ago
    bash runs on windows
    - akdkfe223 3y ago
      Feels a little bit misleading to say that honestly. It runs on windows in what is effectively a chroot/jail/container esque monstrosity. I personally consider that to qualify as a totally separate userspace and therefore not the same operating system as one would assume when you use the term windows without any additional qualifiers.
      - miloignis 3y ago
        Are you referring to WSL/2? The msys2 / Git Bash integration is more integrated with Windows then how I interpret your description.
- drbaba 3y ago
  Many interpreters don’t use Readline (e.g. IPython and Zsh), and enabling inconsistent Vi keybinsings in each one can be a bit annoying. From that perspective, adding it to the terminal seems a possibly easier way to get it “everywhere”?
  - mhitza 3y ago
    Possibly more universal, but there are also tools like rlwrap [1] that adds readline support to programs that don't have it. From the docs apparently the readline library ships a similar tool ootb nowadays but I haven't tried that and just noticed now when I wanted to share the rlwrap link. [1] https://github.com/hanslub42/rlwrap https://github.com/hanslub42/rlwrap
  - williadc 3y ago
    IPython absolutely uses readline
    - drbaba 3y ago
      Not anymore. Since IPython v5 (5+ years ago?), readline was replaced with prompt_toolkit. EDIT: Here’s an official source: https://ipython.readthedocs.io/en/stable/whatsnew/version5.html#ipython-5-0 https://ipython.readthedocs.io/en/stable/whatsnew/version5.h...
- trapnii 3y ago
  To be fair, the vi input mode (or modal input modes) in Contour are way more than simply doing `set -o vi` in bash. You cannot compare those two. The reason why I implemented modal input modes (vi mode) in Contour is, that I noticed Tilix [1] is having vi input modes and people seemed to like it, I wonder if it might be useful to me personally as well, especially since I'm a heavy VIM user, I asked myself if it might make sense to have in a terminal. So let's get it in. I was surprised how much it became part of my daily live, in fact, there's no need to grab the mouse at all when using Contour. You press Ctrl+Shift+Space (configurable) to enter normal mode and move the cursor just like in vim (way beyond the basic support that Alacritty implemented). Especially paired with the indicator statusline support, when showing this one permanently (you can also change the color of that statusline), it became one of the first-class features for me on why I like Contour (not just because I am developing it). Fun things to do (especially when shell integration is enabled): - `yim`: to yank the text in between two markers (that is your command output) - `%`: jump to matching bracket, good when having cat'ed a long json file and you want to quickly browse around - you can also rectangular select like in vim, and then press either p (includes LF) or <S-p> which joins the multiline clipboard text into a single line (removing LF's), that payed off a lot for output like `git status` and wanting to operate on parts of the output (files e.g.) Have a look at the still young website's documentation here: https://contour-terminal.org/input-modes/#supported-text-objects https://contour-terminal.org/input-modes/#supported-text-obj... for a more complete look of what you can do with the keyboard (normal mode) :) [1] https://github.com/thestinger/termite/ https://github.com/thestinger/termite/
amitizle 3y ago
I'm not trying to annoy, I swear. I am using Alacritty for a few years. With tmux config that is moving with me for +- 8 years, except for speed of a terminal emulator, I can't understand the difference between them (other than iTerm2 which is nice but has way too many features)
- bloopernova 3y ago
  I was going to comment something similar. I use iTerm2 day to day for work, and gnome-terminal on my personal Linux box. What's a compelling reason to switch terminals? Or maybe: is there a compelling reason not to switch?
  - sergioisidoro 3y ago
    > is there a compelling reason not to switch? Your terminal emulator is one of the most security sensitive things you use. Sudo password? SSH keys? logs? A lot goes through your terminal, so I think about 5 times before trying out new terminals.
  - eviks 3y ago
    for one, being able to have an identical user experience across all platforms
    - bloopernova 3y ago
      Good point. I share my shell config between Linux and macOS so my UX is mostly the same. Gnome-terminal and iTerm2 act similarly enough that it doesn't really bother me moving between the two.
  - akdkfe223 3y ago
    It depends what kinds of things you find compelling but I would guess probably nothing if you haven't already been sucked into the terminal emulator rabbit hole. iTerm2 and gnome terminal are both perfectly functional for 100% of the tasks you will actually need them for.
  - deleted 3y ago
malablaster 3y ago
I don’t see the point of pitching “fast” as its first selling point. Are people frustrated by the latency of the incumbents?
- user3939382 3y ago
  I’ve never been able to perceive the difference. I use iTerm2 and I can’t perceive how it could be faster.
  - deleted 3y ago
    [deleted]
  - vidarh 3y ago
    Most of the time people only notice the slowness if they are in the habit of regularly letting huge amounts of output stream to the terminal, so it really depends on how you use your terminal. I agree with you - for me terminal speed was a solved issue in mid 1980's, and has not been an issue since.
- ghusbands 3y ago
  Yes. It's common on at least Microsoft terminals to be waiting for the terminal to finish displaying the output it has been sent. I expect that it will be the same for many older terminal emulators.
  - vidarh 3y ago
    Most older terminal emulators tends to do fairly well. E.g. on Linux, rxvt tends to be one of the fastest. Many older terminals tends to do well not least because many older terminals implements jump-scrolling properly (scroll multiple lines at a time before updating the screen if the rendering doesn't keep up) because there are even escape codes to turn that on/off. There's a weird "bathtub curve" when it comes to terminal speed where the oldest tends to be well optimised in terms of tricks to minimise rendering, the newest all tend to concern themselves very much with rendering smart, but often miss the old-school tricks, and quite a few of the ones in the middle are just really naive about everything.
AceJohnny2 3y ago
Does it support `tmux -CC` ? Sorry for being that HN commenter but, if not, I'm bored with yet another terminal that just equates established features. iTerm's killer feature is `tmux -CC` support, so that tmux's sessions are integrated natively. I find it shocking that, years after tmux established this feature, iTerm remains the only terminal emulator to use it.
- riddley 3y ago
  I read the Control Mode section of the man page, but the utility didn't leap off the page. Would you share what's cool about this mode?
  - shmichael 3y ago
    the iterm mode allows one to create, split, resize remote terminals as of they were native terminal windows, instead of all of them being contained within one terminal window and controlled using completely different keyboard-only shortcuts (via tmux)
    - singwhenurdown 3y ago
      does this make it faster? or is it used for the native feel
      - drbaba 3y ago
        Mainly the native feel. For example, you can use standard Cmd-based keybindings to control tabs and panes, and get smooth mouse scrolling in each pane.
  - lanza 3y ago
    sshing into a server only happens within one shell. Thus you can open tmux there and that's the only level of granularity you can have. iterm window->iterm tab->ssh->tmux windows->tmux panes With `tmux -CC` it lets you hoist that chain upwards and map the entire ssh session into an iterm window. iterm window (ssh session) -> iterm tabs (tmux windows) The biggest benefit for me is that you can then open another tmux session within the CC one and use tmux as normal iterm window (ssh session) -> iterm tabs (tmux windows) -> tmux2 windows -> tmux2 panes And then the normal feature of tmux is that it persists across ssh sessions. This also means that the entire iTerm2 window and all its tabs and splits are also maintained across sessions. I think my current layout on my main development machine that I remote into is over 3 months old. Another point of view is that it decouples the state of your tmux tabs/panes from your terminal emulator itself. e.g. if you use this locally instead you could then terminate the entire iterm program and reopen it and restore the same exact window/tab/pane splits you previously had. This is a nice perk for restarting/updating iTerm.
ftyers 3y ago
Does it support Arabic/Devanagari and not do crazy things with BiDi? If so I'm sold!
- slim 3y ago
  do you think mlterm is slow?
  - ftyers 3y ago
    I've not used it, is it good?
    - kps 3y ago
      Not that commenter, but I also use mlterm and have for years, even though I don't normally use BIDI or other ‘exotic’ language capabilities. It is just a terminal, in the do-one-thing-well sense. Its downside is its somewhat idiosyncratic configuration (although there is now a GUI for most of it, so newer users might not notice).
    - slim 3y ago
      it's the best
- Tmpod 3y ago
  It looks like it uses Qt under the hood, so it likely leverages it. Haven't tried yet though.
  - trapnii 3y ago
    Hey, we are using Qt only on the pure frontend GUI side. The rendering itself is using FreeType + HarfBuzz independantly of the GUI. We chose this model explicitly to still be free to replace Qt with something else in the future - iff we have to. The reason behind that decision is, that we actually started with GLFW3, and epically failed, because GLFW3's input model was inferior and the API that I needed was actually marked deprecated by the GLFW3 devs and they also stated that their input model is not good and needs a rework. That led me to the decision to look around and find something else. I only wanted to keep the GUI framework dependency as minimal as possible. We sadly do not have BiDi support just yet, I'd actually love to have that. So far I only know of 2 terminals capable of this: mlterm and gnome-terminal. Unfortunatily I lag the skills of hacking this in except doing it naively. I'd be more than happy for external contributors knowledgable enough in the domain of BiDi, to help us out here. :)
akdkfe223 3y ago
Does anybody know if it's actually fast in terms of low latency? I personally don't care about GPU acceleration or any of those things that Alacritty and others claim makes them fast when the latency is noticeably worse than older non accelerated emulators.
- sprash 3y ago
  If latency is your biggest concern you have to use a terminal emulator without double buffering. So far xterm and mlterm are popular choices.
- angra_mainyu 3y ago
  the latency is excellent, I immediately noticed a huge difference, particularly when seeing the output of long commands (e.g: tail -f)
ur-whale 3y ago
> contour ... actually fast and yet, borderline impossible to install without using flatpak So which is it ? fast or needs flatpak ?
- worksonmine 3y ago
  > So which is it ? fast or needs flatpak? Are they mutually exclusive? If you don't like flatpaks it seems to be available on the AUR, fedora or homebrew if you're using mac. Debian repositories are always lagging behind for new stuff so that's no surprise but the dev provides a script for installing dependencies on the rest of the distributions somewhat customized to your flavor if you're willing to build from source. There is a debian directory so it seems like they started the process of getting included but you'll have to verify in the mailing-lists to see what the current status is. I'd say that's plenty of options to choose from. The simplest being flatpak. Are you a package maintainer yourself? Do you know how much work is involved to get into the main repositories? This is not npm.
- JCWasmx86 3y ago
  It's easy to install on ArchLinux and Fedora. The build process seems to be just standard CMake, so calling it "borderline impossible" is really a stretch.
- diath 3y ago
  How come? It doesn't seem to have any dependencies that you wouldn't be able to get, they're pretty common.
- yjftsjthsd-h 3y ago
  Wait, does flatpak have a runtime performance penalty?
  - doubled112 3y ago
    If I can run Steam and play games packaged with Flatpak, hopefully my machines can handle a terminal emulator too.
mk12 3y ago
There are lots of terminal projects recently. Ghostty (https://mitchellh.com/ghostty https://mitchellh.com/ghostty) and Terminal Click (https://terminal.click https://terminal.click) come to mind. Also Warp and Fig but they don't appeal to me because they're proprietary (and Fig got acquired by Amazon). I've been very happy with kitty (https://sw.kovidgoyal.net/kitty/ https://sw.kovidgoyal.net/kitty/) for years and it would take a lot to make me switch.
- danielvaughn 3y ago
  I wasn't crazy about the proprietary nature of Warp, but I tried it and was sold almost immediately. I can use the same modifier-key commands to select and manipulate text that I'm used to, which feels super nice. They also provide such good sessionization out of the box that I don't really feel the need to install tmux or anything like that.
  - lobsterslive 3y ago
    The problem is that Warp is closed source, requires a log in, has extensive telemetry, promised to go open source but never did and has raised 78M from VCs including 50M from Sequoia, the FTX people.
    - satvikpendem 3y ago
      Indeed, VCs will want a return on their investment at some point, and it doesn't seem like simply sharing some terminal commands in the cloud with your team will be enough to justify that valuation. This is especially true as the Zero Interest Rate Phenomenon of the last 15 years is now over. Personally I'd never use something VC backed for something so critical to my productivity.
      - alchemist1e9 3y ago
        Having never heard of Warp and wondering what would get VCs to give that much to a terminal project I just took look at their website and it’s obviously the AI/LLM aspect. With that said does anyone know which open source projects are looking at LLM integration. It’s not a bad idea.
tiffanyh 3y ago
A prominent blog post benchmarking latency of various terminals. https://danluu.com/term-latency/ https://danluu.com/term-latency/ TL;DR; terminal.app on macOS is typically the fastest.
- idoubtit 3y ago
  Your benchmark is more than 6 years old, on a 2014 Macbook, with a strange choice of terminals. LWN's article on the subject is almost as old, but with a better comparison: https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/ (2018) For a recent take, though by one of the competitors, see https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty > TL;DR; terminal.app on macOS is typically the fastest. Even on macOS, that's probably not true, at least nowadays. See https://www.lkhrs.com/blog/2022/07/terminal-latency/ https://www.lkhrs.com/blog/2022/07/terminal-latency/ (2022)
  - 4death4 3y ago
    It says Terminal.app follows closely behind the fastest. This level of discussion around “fast” terminals is funny to me. I’ve always used Terminal.app and never had a single problem. It turns out the default option is likely the best in this case.
pmarreck 3y ago
Wezterm is my jam https://wezfurlong.org/wezterm/ https://wezfurlong.org/wezterm/
- sprash 3y ago
  Really cool, the parallax background scrolling feature: https://wezfurlong.org/wezterm/config/lua/config/background.html https://wezfurlong.org/wezterm/config/lua/config/background....
  - pmarreck 3y ago
    I didn't even know it had that feature until now, LOL, nice!
- cormullion 3y ago
  Overall I think Wezterm has the best font support (and the best support).
masto 3y ago
What’s modal about it? I’m also in the “I’ve never wished my terminal were faster” camp. Certainly I’ve wished the things I run in it were faster, but that’s a different story. I split my time between macOS and ChromeOS, and I find it easier to just stick to what’s built in. The things that add friction to my development experience are not waiting for tty characters to draw, they are hopping around between the mess of tabs and windows between the browser, VS Code, and terminal sessions, all tied for a distant third; in second place, waiting for builds; and by far and away #1, trying to understand how this goddamn maze of abstraction and indirection and microservices and frameworks works so I can figure out where to actually put my code.
- mistercow 3y ago
  > I’m also in the “I’ve never wished my terminal were faster” camp. In the long long ago, I remember having to limit my terminal scrollback to avoid things getting laggy. That hasn’t been the case for a long time, because terminals started taking performance seriously. So I think advertising speed is more of a table stakes situation than a competitive advantage. I want to see that a new terminal emulator is thinking about speed because if they’re not, I can probably rule them out as an option immediately.
  - ElCapitanMarkla 3y ago
    I hadn’t had this issue for years, about 4 months ago I started at a new company which had a big rails monolith. I’m now super conscious of ever resizing iterm, if I leave a terminal running for more than a day resizing the terminal brings the entire laptop to its knees.
- maccard 3y ago
  > I’m also in the “I’ve never wished my terminal were faster” camp. I have an application that I run daily that is noticeably (15-20%) faster if I redirect terminal output to a file, or if I use a non-default terminal emulator. In this day and age, not being able to keep up with drawing 80 x 24 even with unicode is just not acceptable.
- trapnii 3y ago
IshKebab 3y ago
It would be nice if someone worked on actually improving the terminal experience. Selecting, copying and pasting text is still pretty awful (why is the cursor an entire block rather than a I bar?). Editing multiline inputs is awful. Navigating history is so-so (even with McFly etc.). Anything more complicated than left/right/up/down fails half the time and dumps control characters instead. Why are terminals always stuck in the 70s? Can I get a modern terminal?
- paradox460 3y ago
  Fwiw, iTerm2 has a "copy mode" which lets you navigate around and yank the visible terminal and scrollback with vim bindings
- Macha 3y ago
  There are better experiences (e.g. my shell has vi mode which is much nicer for editing multi-line inputs, I'm sure if I could be bothered to learn emacs/readline shortcuts that'd be another set) but they're not easily discoverable and a bit unevenly distributed.
- indymike 3y ago
  > Editing multiline inputs is awful. Outside of "line at a time" i/o (a rarely used mode where an entire line is edited locally and then sent to the host), most of what users see is as interactive is controlled by the program you are interacting with. The terminal just takes commands from the host and does what it is told. BTW, line at a time mode isn't used that much. The only thing I use that uses line at a time mode is telenet in LINEMODE. > Navigating history is so-so Yes, that is because the program you are likely interacting with where history is relevant implements it's own repl or command line (i.e. bash, zsh, python, etc...) and it is responsible for it's own history and may implement it completely differently than say, bash or zsh. > Why are terminals always stuck in the 70s? Can I get a modern terminal? We do have a modern terminal: the web browser... and it's pretty nice. There have been a ton of tries at more modern terminals, but ultimately, they end up really being limited by the software running in the terminal session. In the 90s we had a ton of commercial terminal emulators that would allow you to create full guis, complete with dialogs and forms. In the 00's there were a few tries at terminals that would allow html output and embedding of html forms for input (can't remember the names of them). I suppose there's also the whole X11 thing... which is so good enough that it's really hard to kill. Let's get back to character mode: A lot of interactive terminal software is built using different libraries - so sometimes you get a terminal gui based on ncurses, terminal.gui, or something else... here's a list: https://github.com/rothgar/awesome-tuis#libraries https://github.com/rothgar/awesome-tuis#libraries. Most of these libraries try to use most of the features in your terminal emulator, but often, just use stuff that is in everything. For command line programs (i.e. just type a command), a lot of the experience is dictated by the parser used by the tool and whatever the underlying operating system has for passing arguments. Some shells and terminal emulators (like iTerm2 on mac) try to smooth this out, but again, there's a lot of variety in command line parsers. Probably the biggest modern improvement in the shell world was gettext and various command-line completion libraries which allows command parameter completion if the developer supports it or uses a parser that supports completion. But none of this is the terminal itself doing the work.
mgaunard 3y ago
I use terminator because it's reasonably lightweight (despite being written in python) and has good tab and split screen support. I'm not interested in tmux since I work on my computer directly. Is there anything with a comparable feature set that's faster? I couldn't care less about Mac or Windows support.
- mhitza 3y ago
  I've been using terminator as well for who knows how many years at this point, and aside from the startup I don't percieve it as slow. What, or in which circumstances exactly do you feel your terminal emulator is slow and would need to be faster?
- whalesalad 3y ago
  Tmux is great even for local dev. I use it locally and remotely. You might like to try kitty.
  - snapplebobapple 3y ago
    Keep am eye on zellij, its almost there for me for making me gice up my tmux that i put a lot of work getting just right
- abnry 3y ago
  The GUI style choices turn me off to terminator. Silly reason. Maybe I should look at changing defaults.
Tempest1981 3y ago
How do I check if my older CPU has AES-NI? > Requirements: CPU: x86-64 AMD or Intel with AES-NI instruction set or ARMv8 with crypto extensions. Edit: maybe https://en.wikipedia.org/wiki/AES_instruction_set#Intel https://en.wikipedia.org/wiki/AES_instruction_set#Intel
- SushiHippie 3y ago
  The lscpu command will you show you. IIUC you need to have "aes" under the flags entry.
- trapnii 3y ago
  We finally have a software-fallback, and do not hard-depend on AES-NI anymore. But if it's present, we'll use it (also its equivalent on ARM64)
MightyBuzzard 3y ago
[dead]
cout 3y ago
I am always pleased to see code that is reasonably clean and uses modern C++. Sixel support is also nice to see. For all its faults, I think it's the only pixel graphics extension that currently has a chance of widespread adoption. I am curious if the authors have made any attempts to quantify "fast". Are there any benchmarks? In particular, I would love to see some input latency comparisons.
- trapnii 3y ago
  simply put, yes. but I know very well that performance can be measured in many different dimensions and ways. I optimize for speed for my own personal use-cases (vim should be fluent as well as notcurses-demo as well as cat'ing large output). Especially cat-style benchmarking is what YT-channels like to do, right next to `time tree /`. We do not claim to be THE fastest (unless you find out why, but pssst, don't tell anyone), because I do not want to start a performance war on some metric that is almost useless for the regular and even power user. Input latency, oof, last time I actually took the time to check, it was similar to KDE konsole. I used some Java based tool to measure this, IIRC I've got this from an LWN article. But now, I'm not having the time to do this again, especially since I feel like there's more important stuff on our plate, that I really want to get done in 2023 (e.g. getting out the next stable release). :) If anyone of the power users opts to re-visit perf benchmarking on the modern TEs compared to the classic ones, I'd be one amongst the first to gladly read though ;)
konart 3y ago
How does it compare to Alacrtitty, Kitty, Wezterm, Rio and other moder and actually fast terminal emulators?
- souvlakee 3y ago
  Recently discovered Rio and it works faster than everything GPU accelerated I've ever tried. Believe that's because WebGL.
  - trapnii 3y ago
    This doesn't make sense. WebGL is as GPU accelerated as the other young'ish GPU accelerated terminals, except that they're not running in the browser, which should(tm) make them run faster. On the other hand, rendering is just one thing to benchmark, there is input latency (already mentioned in this thread here somewhere), but also (terminal / PTY) bandwidth throughput. This is three categories where 2 of the 3 are not related to "GPU acceleration" at all. :)
Stem0037 3y ago
I remember the days when I had to juggle between different emulators just to get a fraction of these features...
blueflow 3y ago
Prerequisites: ./scripts/install-deps.sh Please don't do this! List your dependencies normally. Packaging OSS projects is difficult enough already.
- jraph 3y ago
  I don't know. If the script is legible, that's an executable (and therefore probably tested), exact documentation. edit: yep, I just took a look and can confirm, it takes a few seconds to get the list of dependencies for several distributions. It's way better than most readmes.
czottmann 3y ago
> Available on all 4 major platforms, Linux, OS/X, FreeBSD, Windows I know it's nitpicky, but it's "macOS" since 2016, i.e. it stopped being "OS X" or "OSX" about 7 years ago.
tmtvl 3y ago
I like that they reference the VT510 manual, if the terminal implements the more advanced control codes then individual applications can do their work without needing to rely on their own implementations of the needed functionality. I'm gonna give Vttest a whirl in Contour and if it does well I'll try daily driving it for a while.
- trapnii 3y ago
  Please give us feedback in the issue tracker. We know we're not perfect, but certainly very much appreciate positive constructive feedback as well as bug reports. p.s.: I did not submit this link here, I intentionally try to avoid that, but I am surprised by the amount of people talking about terminals generally speaking here in this thread, even though a lot of comments (didn't finish yet) seem to be non-Contour related :)
deleted 3y ago
[deleted]
cmrdporcupine 3y ago
Looks nice, but seeming lack of tabs support (https://github.com/contour-terminal/contour/issues/90 https://github.com/contour-terminal/contour/issues/90) makes it a hard sell for me.
tupolef 3y ago
I just tried it and I will keep an eye on it for later. Currently it is a work in progress and there is a lot of issues with the dependencies and compatibility with legacy setups, but it is way better than Warp and other GPU terminals that I tried. I am currently a happy user of Urxvt and intend to continue until I am forced to switch to wayland (in a long time, I hope). In comparaison I have to add that the rendering in more defined in Urxvt that Contour even after tinkering, and like always it uses at least 5 times less memory.
- trapnii 3y ago
  > In comparaison I have to add that the rendering in more defined in Urxvt that Contour even after tinkering, Nothing is perfect. Many thanks for trying though. If you don't mind, maybe you could file a report in github.com/contour-terminal/contour/issues/ such that we know about it, can track it, and also, report back to you, once it's improved? Generally speaking, it's hard to say that rendering is that bad, because we simply use FreeType for glyph rasterization as well as Harfbuzz for text shaping. That doesn't mean it's perfect. I know that not everybody likes lcd subpixel rendering in Contour, and that anti-aliasing (AA) methods are generally highly subjective on what the best AA method is. We implement multiple such that most users should find what they like the most. If that still doesn't fit, I'd like to know about it, so we can hopefully fix it, just in case it is a bug on Contour's end. > and like always it uses at least 5 times less memory That's not a good metric to look at, at least it's not enough info to judge about. I recently read a guy comparing the memory resource usage of many terminals when having 2,000,000 lines of history configured and found Contour to be the winner here. This doesn't mean much though. I think just looking at the memory consumption is not enough to reason about it. I do agree however, that it should not blindlingly grow over time to something unreasonable. We try not to carelessly allocate any resource, so I'm pretty certain that we're doing "okay" in terms of RAM requirements.
  - tupolef 3y ago
    I will find some time to write an issue about the rendering. And you're right, contour is doing okay in terms of memory, especially compared with other modern terminals. It's just that the first run after built uses already 250mb, and I think that when I will setup some fonts and run a few panes inside it will probably go higher. But if it stays around this number, it's really fine.
Conscat 3y ago
https://github.com/contour-terminal/contour/issues/382 https://github.com/contour-terminal/contour/issues/382 This apparently does not support the Kitty graphics protocol, just Sixel, which makes it look fairly unattractive to me, personally.
- trapnii 3y ago
  There are many reasons for me to not have kitty protocol implemented. Objectively speaking, I try to mention only one here: Sixel seems to have raised attraction across the whole terminal community over the past years and gets stronger adoption over other image protocols. Ah, and a second one: Kitty's image protocol is slow, purely performance-wise speaking. As an end-user that simply wants to cat an image, it probably won't be noticable, and our Sixel implementation isn't the fastest on earth either, but I welcome any contribution to Contour.
  - aumerle 3y ago
    What nonsense. kitty's graphics protocol is literally infinitely faster than sixels for local transmission and the same speed as sixels for remote transmission, taking into account that kitty's graphics protocol supports 32bit colors, unlike sixel.
    - trapnii 3y ago
      This is interesting. I am trying not to feel offended by your toxic play, so let's get started: > kitty's graphics protocol is literally infinitely faster than sixels for local transmission Let's get the comparison right here (not apples with pies), Kitty graphics over the PTY wire is slower than Sixel over the PTY wire. Kitty supports bypassing the PTY by just referencing to a file locally present on the file system or using n SHM region on the local memory. Both solutions won't work over the internet, because they break the VT I/O model. But you are right, when bypassing the wire, it'll be faster. That sadly limits you to local-only use. > literally infinitely faster I wonder what your math behind this is :-P > taking into account that kitty's graphics protocol supports 32bit colors, unlike sixel Sixel is using a palette to define the colors to reference from. This pallete can be either in Hue or in RGB format. Of course, the palette has limited amount of entries (which can be queried), but during the image transmittion, just adjust your palette, to get a breader range of colors to chose from. It's still RGB, or to be more precise RRGGBB (8-bit red/green/blue components, which makes it 24-bit. I wonder if what you mean with 32-bit colors other than 24-bit colors plus 8-bit alpha. Alpha values is something that is not supported by sixel (wrong age for Sixels :D), but still it is possible to render images that do not cover only rectangular parts. For example that image here: https://contour-terminal.org/screenshots/contour-notcurses-ncneofetch.png https://contour-terminal.org/screenshots/contour-notcurses-n... - look at the logo. But I agree, semi-transarent images are not possible using Sixels. But then, you probably want to use a GUI then :)
politelemon 3y ago
Any idea why nvtop wouldn't work on it? I run nvtop and get "Error opening terminal: contour."
- trapnii 3y ago
  How did you install Contour and what is the TERM environment variable set to and is your terminfo properly resolved? I just asked someone with an AMD/NVIDIA card to try out nvtop inside Contour and it worked. So I assume maybe there is something fishy with your TERM/terminfo configuration.
muhammadusman 3y ago
Once in awhile I’ll try these new emulators but I keep going back to iTerm2. Maybe having a comparison of the two or similar would help convince me and others in the same boat.
fefe23 3y ago
I would love it if it became standard practice for projects to list their dependencies. I was going to try this but it wanted to pull in Catch2 (some unit testing framework) and apparently has a dependency on Qt. It is good and nice if your project has unit tests, and by all means use a framework if you think you need one. But don't make me install your framework just so I can do a standard release build. Only require it for building and performing the unit tests. If the home page mentioned the Qt dependency, I wouldn't have downloaded the source code.
da39a3ee 3y ago
I've in the camp of never noticed my terminal emulator being slow. Used iTerm2 for 10 years, switched to Alacritty recently for reasons unrelated to performance. Before iTerm2 on Linux I don't really remember what I used but I don't remember it being slow. Haven't noticed scrolling speed being slow, and I don't get this "insert latency" obsession.

181 points by ingve 3y ago

kelsey9876543 3y ago

i don't see the point of adding vi input mode to the emulator when we have it inside bash with `set -o vi`

Gualdrapo 3y ago
As it supports Windows, I guess it would be useful for them
- kelsey9876543 3y ago
  bash runs on windows
  - akdkfe223 3y ago
    Feels a little bit misleading to say that honestly. It runs on windows in what is effectively a chroot/jail/container esque monstrosity. I personally consider that to qualify as a totally separate userspace and therefore not the same operating system as one would assume when you use the term windows without any additional qualifiers.
    - miloignis 3y ago
      Are you referring to WSL/2? The msys2 / Git Bash integration is more integrated with Windows then how I interpret your description.
drbaba 3y ago
Many interpreters don’t use Readline (e.g. IPython and Zsh), and enabling inconsistent Vi keybinsings in each one can be a bit annoying. From that perspective, adding it to the terminal seems a possibly easier way to get it “everywhere”?
- mhitza 3y ago
  Possibly more universal, but there are also tools like rlwrap [1] that adds readline support to programs that don't have it. From the docs apparently the readline library ships a similar tool ootb nowadays but I haven't tried that and just noticed now when I wanted to share the rlwrap link. [1] https://github.com/hanslub42/rlwrap https://github.com/hanslub42/rlwrap
- williadc 3y ago
  IPython absolutely uses readline
  - drbaba 3y ago
    Not anymore. Since IPython v5 (5+ years ago?), readline was replaced with prompt_toolkit. EDIT: Here’s an official source: https://ipython.readthedocs.io/en/stable/whatsnew/version5.html#ipython-5-0 https://ipython.readthedocs.io/en/stable/whatsnew/version5.h...
trapnii 3y ago
To be fair, the vi input mode (or modal input modes) in Contour are way more than simply doing `set -o vi` in bash. You cannot compare those two. The reason why I implemented modal input modes (vi mode) in Contour is, that I noticed Tilix [1] is having vi input modes and people seemed to like it, I wonder if it might be useful to me personally as well, especially since I'm a heavy VIM user, I asked myself if it might make sense to have in a terminal. So let's get it in. I was surprised how much it became part of my daily live, in fact, there's no need to grab the mouse at all when using Contour. You press Ctrl+Shift+Space (configurable) to enter normal mode and move the cursor just like in vim (way beyond the basic support that Alacritty implemented). Especially paired with the indicator statusline support, when showing this one permanently (you can also change the color of that statusline), it became one of the first-class features for me on why I like Contour (not just because I am developing it). Fun things to do (especially when shell integration is enabled): - `yim`: to yank the text in between two markers (that is your command output) - `%`: jump to matching bracket, good when having cat'ed a long json file and you want to quickly browse around - you can also rectangular select like in vim, and then press either p (includes LF) or <S-p> which joins the multiline clipboard text into a single line (removing LF's), that payed off a lot for output like `git status` and wanting to operate on parts of the output (files e.g.) Have a look at the still young website's documentation here: https://contour-terminal.org/input-modes/#supported-text-objects https://contour-terminal.org/input-modes/#supported-text-obj... for a more complete look of what you can do with the keyboard (normal mode) :) [1] https://github.com/thestinger/termite/ https://github.com/thestinger/termite/

amitizle 3y ago

I'm not trying to annoy, I swear. I am using Alacritty for a few years. With tmux config that is moving with me for +- 8 years, except for speed of a terminal emulator, I can't understand the difference between them (other than iTerm2 which is nice but has way too many features)

bloopernova 3y ago
I was going to comment something similar. I use iTerm2 day to day for work, and gnome-terminal on my personal Linux box. What's a compelling reason to switch terminals? Or maybe: is there a compelling reason not to switch?
- sergioisidoro 3y ago
  > is there a compelling reason not to switch? Your terminal emulator is one of the most security sensitive things you use. Sudo password? SSH keys? logs? A lot goes through your terminal, so I think about 5 times before trying out new terminals.
- eviks 3y ago
  for one, being able to have an identical user experience across all platforms
  - bloopernova 3y ago
    Good point. I share my shell config between Linux and macOS so my UX is mostly the same. Gnome-terminal and iTerm2 act similarly enough that it doesn't really bother me moving between the two.
- akdkfe223 3y ago
  It depends what kinds of things you find compelling but I would guess probably nothing if you haven't already been sucked into the terminal emulator rabbit hole. iTerm2 and gnome terminal are both perfectly functional for 100% of the tasks you will actually need them for.
- deleted 3y ago

malablaster 3y ago

I don’t see the point of pitching “fast” as its first selling point. Are people frustrated by the latency of the incumbents?

user3939382 3y ago
I’ve never been able to perceive the difference. I use iTerm2 and I can’t perceive how it could be faster.
- deleted 3y ago
  [deleted]
- vidarh 3y ago
  Most of the time people only notice the slowness if they are in the habit of regularly letting huge amounts of output stream to the terminal, so it really depends on how you use your terminal. I agree with you - for me terminal speed was a solved issue in mid 1980's, and has not been an issue since.
ghusbands 3y ago
Yes. It's common on at least Microsoft terminals to be waiting for the terminal to finish displaying the output it has been sent. I expect that it will be the same for many older terminal emulators.
- vidarh 3y ago
  Most older terminal emulators tends to do fairly well. E.g. on Linux, rxvt tends to be one of the fastest. Many older terminals tends to do well not least because many older terminals implements jump-scrolling properly (scroll multiple lines at a time before updating the screen if the rendering doesn't keep up) because there are even escape codes to turn that on/off. There's a weird "bathtub curve" when it comes to terminal speed where the oldest tends to be well optimised in terms of tricks to minimise rendering, the newest all tend to concern themselves very much with rendering smart, but often miss the old-school tricks, and quite a few of the ones in the middle are just really naive about everything.

AceJohnny2 3y ago

Does it support `tmux -CC` ? Sorry for being that HN commenter but, if not, I'm bored with yet another terminal that just equates established features. iTerm's killer feature is `tmux -CC` support, so that tmux's sessions are integrated natively. I find it shocking that, years after tmux established this feature, iTerm remains the only terminal emulator to use it.

riddley 3y ago
I read the Control Mode section of the man page, but the utility didn't leap off the page. Would you share what's cool about this mode?
- shmichael 3y ago
  the iterm mode allows one to create, split, resize remote terminals as of they were native terminal windows, instead of all of them being contained within one terminal window and controlled using completely different keyboard-only shortcuts (via tmux)
  - singwhenurdown 3y ago
    does this make it faster? or is it used for the native feel
    - drbaba 3y ago
      Mainly the native feel. For example, you can use standard Cmd-based keybindings to control tabs and panes, and get smooth mouse scrolling in each pane.
- lanza 3y ago
  sshing into a server only happens within one shell. Thus you can open tmux there and that's the only level of granularity you can have. iterm window->iterm tab->ssh->tmux windows->tmux panes With `tmux -CC` it lets you hoist that chain upwards and map the entire ssh session into an iterm window. iterm window (ssh session) -> iterm tabs (tmux windows) The biggest benefit for me is that you can then open another tmux session within the CC one and use tmux as normal iterm window (ssh session) -> iterm tabs (tmux windows) -> tmux2 windows -> tmux2 panes And then the normal feature of tmux is that it persists across ssh sessions. This also means that the entire iTerm2 window and all its tabs and splits are also maintained across sessions. I think my current layout on my main development machine that I remote into is over 3 months old. Another point of view is that it decouples the state of your tmux tabs/panes from your terminal emulator itself. e.g. if you use this locally instead you could then terminate the entire iterm program and reopen it and restore the same exact window/tab/pane splits you previously had. This is a nice perk for restarting/updating iTerm.

ftyers 3y ago

Does it support Arabic/Devanagari and not do crazy things with BiDi? If so I'm sold!

slim 3y ago
do you think mlterm is slow?
- ftyers 3y ago
  I've not used it, is it good?
  - kps 3y ago
    Not that commenter, but I also use mlterm and have for years, even though I don't normally use BIDI or other ‘exotic’ language capabilities. It is just a terminal, in the do-one-thing-well sense. Its downside is its somewhat idiosyncratic configuration (although there is now a GUI for most of it, so newer users might not notice).
  - slim 3y ago
    it's the best
Tmpod 3y ago
It looks like it uses Qt under the hood, so it likely leverages it. Haven't tried yet though.
- trapnii 3y ago
  Hey, we are using Qt only on the pure frontend GUI side. The rendering itself is using FreeType + HarfBuzz independantly of the GUI. We chose this model explicitly to still be free to replace Qt with something else in the future - iff we have to. The reason behind that decision is, that we actually started with GLFW3, and epically failed, because GLFW3's input model was inferior and the API that I needed was actually marked deprecated by the GLFW3 devs and they also stated that their input model is not good and needs a rework. That led me to the decision to look around and find something else. I only wanted to keep the GUI framework dependency as minimal as possible. We sadly do not have BiDi support just yet, I'd actually love to have that. So far I only know of 2 terminals capable of this: mlterm and gnome-terminal. Unfortunatily I lag the skills of hacking this in except doing it naively. I'd be more than happy for external contributors knowledgable enough in the domain of BiDi, to help us out here. :)

akdkfe223 3y ago

Does anybody know if it's actually fast in terms of low latency? I personally don't care about GPU acceleration or any of those things that Alacritty and others claim makes them fast when the latency is noticeably worse than older non accelerated emulators.

sprash 3y ago
If latency is your biggest concern you have to use a terminal emulator without double buffering. So far xterm and mlterm are popular choices.
angra_mainyu 3y ago
the latency is excellent, I immediately noticed a huge difference, particularly when seeing the output of long commands (e.g: tail -f)

ur-whale 3y ago

> contour ... actually fast and yet, borderline impossible to install without using flatpak So which is it ? fast or needs flatpak ?

worksonmine 3y ago
> So which is it ? fast or needs flatpak? Are they mutually exclusive? If you don't like flatpaks it seems to be available on the AUR, fedora or homebrew if you're using mac. Debian repositories are always lagging behind for new stuff so that's no surprise but the dev provides a script for installing dependencies on the rest of the distributions somewhat customized to your flavor if you're willing to build from source. There is a debian directory so it seems like they started the process of getting included but you'll have to verify in the mailing-lists to see what the current status is. I'd say that's plenty of options to choose from. The simplest being flatpak. Are you a package maintainer yourself? Do you know how much work is involved to get into the main repositories? This is not npm.
JCWasmx86 3y ago
It's easy to install on ArchLinux and Fedora. The build process seems to be just standard CMake, so calling it "borderline impossible" is really a stretch.
diath 3y ago
How come? It doesn't seem to have any dependencies that you wouldn't be able to get, they're pretty common.
yjftsjthsd-h 3y ago
Wait, does flatpak have a runtime performance penalty?
- doubled112 3y ago
  If I can run Steam and play games packaged with Flatpak, hopefully my machines can handle a terminal emulator too.

mk12 3y ago

There are lots of terminal projects recently. Ghostty (https://mitchellh.com/ghostty https://mitchellh.com/ghostty) and Terminal Click (https://terminal.click https://terminal.click) come to mind. Also Warp and Fig but they don't appeal to me because they're proprietary (and Fig got acquired by Amazon). I've been very happy with kitty (https://sw.kovidgoyal.net/kitty/ https://sw.kovidgoyal.net/kitty/) for years and it would take a lot to make me switch.

danielvaughn 3y ago
I wasn't crazy about the proprietary nature of Warp, but I tried it and was sold almost immediately. I can use the same modifier-key commands to select and manipulate text that I'm used to, which feels super nice. They also provide such good sessionization out of the box that I don't really feel the need to install tmux or anything like that.
- lobsterslive 3y ago
  The problem is that Warp is closed source, requires a log in, has extensive telemetry, promised to go open source but never did and has raised 78M from VCs including 50M from Sequoia, the FTX people.
  - satvikpendem 3y ago
    Indeed, VCs will want a return on their investment at some point, and it doesn't seem like simply sharing some terminal commands in the cloud with your team will be enough to justify that valuation. This is especially true as the Zero Interest Rate Phenomenon of the last 15 years is now over. Personally I'd never use something VC backed for something so critical to my productivity.
    - alchemist1e9 3y ago
      Having never heard of Warp and wondering what would get VCs to give that much to a terminal project I just took look at their website and it’s obviously the AI/LLM aspect. With that said does anyone know which open source projects are looking at LLM integration. It’s not a bad idea.

tiffanyh 3y ago

A prominent blog post benchmarking latency of various terminals. https://danluu.com/term-latency/ https://danluu.com/term-latency/ TL;DR; terminal.app on macOS is typically the fastest.

idoubtit 3y ago
Your benchmark is more than 6 years old, on a 2014 Macbook, with a strange choice of terminals. LWN's article on the subject is almost as old, but with a better comparison: https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/ (2018) For a recent take, though by one of the competitors, see https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty > TL;DR; terminal.app on macOS is typically the fastest. Even on macOS, that's probably not true, at least nowadays. See https://www.lkhrs.com/blog/2022/07/terminal-latency/ https://www.lkhrs.com/blog/2022/07/terminal-latency/ (2022)
- 4death4 3y ago
  It says Terminal.app follows closely behind the fastest. This level of discussion around “fast” terminals is funny to me. I’ve always used Terminal.app and never had a single problem. It turns out the default option is likely the best in this case.

pmarreck 3y ago

Wezterm is my jam https://wezfurlong.org/wezterm/ https://wezfurlong.org/wezterm/

sprash 3y ago
Really cool, the parallax background scrolling feature: https://wezfurlong.org/wezterm/config/lua/config/background.html https://wezfurlong.org/wezterm/config/lua/config/background....
- pmarreck 3y ago
  I didn't even know it had that feature until now, LOL, nice!
cormullion 3y ago
Overall I think Wezterm has the best font support (and the best support).

masto 3y ago

What’s modal about it? I’m also in the “I’ve never wished my terminal were faster” camp. Certainly I’ve wished the things I run in it were faster, but that’s a different story. I split my time between macOS and ChromeOS, and I find it easier to just stick to what’s built in. The things that add friction to my development experience are not waiting for tty characters to draw, they are hopping around between the mess of tabs and windows between the browser, VS Code, and terminal sessions, all tied for a distant third; in second place, waiting for builds; and by far and away #1, trying to understand how this goddamn maze of abstraction and indirection and microservices and frameworks works so I can figure out where to actually put my code.

mistercow 3y ago
> I’m also in the “I’ve never wished my terminal were faster” camp. In the long long ago, I remember having to limit my terminal scrollback to avoid things getting laggy. That hasn’t been the case for a long time, because terminals started taking performance seriously. So I think advertising speed is more of a table stakes situation than a competitive advantage. I want to see that a new terminal emulator is thinking about speed because if they’re not, I can probably rule them out as an option immediately.
- ElCapitanMarkla 3y ago
  I hadn’t had this issue for years, about 4 months ago I started at a new company which had a big rails monolith. I’m now super conscious of ever resizing iterm, if I leave a terminal running for more than a day resizing the terminal brings the entire laptop to its knees.
maccard 3y ago
> I’m also in the “I’ve never wished my terminal were faster” camp. I have an application that I run daily that is noticeably (15-20%) faster if I redirect terminal output to a file, or if I use a non-default terminal emulator. In this day and age, not being able to keep up with drawing 80 x 24 even with unicode is just not acceptable.
trapnii 3y ago

IshKebab 3y ago

It would be nice if someone worked on actually improving the terminal experience. Selecting, copying and pasting text is still pretty awful (why is the cursor an entire block rather than a I bar?). Editing multiline inputs is awful. Navigating history is so-so (even with McFly etc.). Anything more complicated than left/right/up/down fails half the time and dumps control characters instead. Why are terminals always stuck in the 70s? Can I get a modern terminal?

paradox460 3y ago
Fwiw, iTerm2 has a "copy mode" which lets you navigate around and yank the visible terminal and scrollback with vim bindings
Macha 3y ago
There are better experiences (e.g. my shell has vi mode which is much nicer for editing multi-line inputs, I'm sure if I could be bothered to learn emacs/readline shortcuts that'd be another set) but they're not easily discoverable and a bit unevenly distributed.
indymike 3y ago
> Editing multiline inputs is awful. Outside of "line at a time" i/o (a rarely used mode where an entire line is edited locally and then sent to the host), most of what users see is as interactive is controlled by the program you are interacting with. The terminal just takes commands from the host and does what it is told. BTW, line at a time mode isn't used that much. The only thing I use that uses line at a time mode is telenet in LINEMODE. > Navigating history is so-so Yes, that is because the program you are likely interacting with where history is relevant implements it's own repl or command line (i.e. bash, zsh, python, etc...) and it is responsible for it's own history and may implement it completely differently than say, bash or zsh. > Why are terminals always stuck in the 70s? Can I get a modern terminal? We do have a modern terminal: the web browser... and it's pretty nice. There have been a ton of tries at more modern terminals, but ultimately, they end up really being limited by the software running in the terminal session. In the 90s we had a ton of commercial terminal emulators that would allow you to create full guis, complete with dialogs and forms. In the 00's there were a few tries at terminals that would allow html output and embedding of html forms for input (can't remember the names of them). I suppose there's also the whole X11 thing... which is so good enough that it's really hard to kill. Let's get back to character mode: A lot of interactive terminal software is built using different libraries - so sometimes you get a terminal gui based on ncurses, terminal.gui, or something else... here's a list: https://github.com/rothgar/awesome-tuis#libraries https://github.com/rothgar/awesome-tuis#libraries. Most of these libraries try to use most of the features in your terminal emulator, but often, just use stuff that is in everything. For command line programs (i.e. just type a command), a lot of the experience is dictated by the parser used by the tool and whatever the underlying operating system has for passing arguments. Some shells and terminal emulators (like iTerm2 on mac) try to smooth this out, but again, there's a lot of variety in command line parsers. Probably the biggest modern improvement in the shell world was gettext and various command-line completion libraries which allows command parameter completion if the developer supports it or uses a parser that supports completion. But none of this is the terminal itself doing the work.

mgaunard 3y ago

I use terminator because it's reasonably lightweight (despite being written in python) and has good tab and split screen support. I'm not interested in tmux since I work on my computer directly. Is there anything with a comparable feature set that's faster? I couldn't care less about Mac or Windows support.

mhitza 3y ago
I've been using terminator as well for who knows how many years at this point, and aside from the startup I don't percieve it as slow. What, or in which circumstances exactly do you feel your terminal emulator is slow and would need to be faster?
whalesalad 3y ago
Tmux is great even for local dev. I use it locally and remotely. You might like to try kitty.
- snapplebobapple 3y ago
  Keep am eye on zellij, its almost there for me for making me gice up my tmux that i put a lot of work getting just right
abnry 3y ago
The GUI style choices turn me off to terminator. Silly reason. Maybe I should look at changing defaults.

Tempest1981 3y ago

How do I check if my older CPU has AES-NI? > Requirements: CPU: x86-64 AMD or Intel with AES-NI instruction set or ARMv8 with crypto extensions. Edit: maybe https://en.wikipedia.org/wiki/AES_instruction_set#Intel https://en.wikipedia.org/wiki/AES_instruction_set#Intel

SushiHippie 3y ago
The lscpu command will you show you. IIUC you need to have "aes" under the flags entry.
trapnii 3y ago
We finally have a software-fallback, and do not hard-depend on AES-NI anymore. But if it's present, we'll use it (also its equivalent on ARM64)

MightyBuzzard 3y ago

[dead]

cout 3y ago

I am always pleased to see code that is reasonably clean and uses modern C++. Sixel support is also nice to see. For all its faults, I think it's the only pixel graphics extension that currently has a chance of widespread adoption. I am curious if the authors have made any attempts to quantify "fast". Are there any benchmarks? In particular, I would love to see some input latency comparisons.

trapnii 3y ago
simply put, yes. but I know very well that performance can be measured in many different dimensions and ways. I optimize for speed for my own personal use-cases (vim should be fluent as well as notcurses-demo as well as cat'ing large output). Especially cat-style benchmarking is what YT-channels like to do, right next to `time tree /`. We do not claim to be THE fastest (unless you find out why, but pssst, don't tell anyone), because I do not want to start a performance war on some metric that is almost useless for the regular and even power user. Input latency, oof, last time I actually took the time to check, it was similar to KDE konsole. I used some Java based tool to measure this, IIRC I've got this from an LWN article. But now, I'm not having the time to do this again, especially since I feel like there's more important stuff on our plate, that I really want to get done in 2023 (e.g. getting out the next stable release). :) If anyone of the power users opts to re-visit perf benchmarking on the modern TEs compared to the classic ones, I'd be one amongst the first to gladly read though ;)

konart 3y ago

How does it compare to Alacrtitty, Kitty, Wezterm, Rio and other moder and actually fast terminal emulators?

souvlakee 3y ago
Recently discovered Rio and it works faster than everything GPU accelerated I've ever tried. Believe that's because WebGL.
- trapnii 3y ago
  This doesn't make sense. WebGL is as GPU accelerated as the other young'ish GPU accelerated terminals, except that they're not running in the browser, which should(tm) make them run faster. On the other hand, rendering is just one thing to benchmark, there is input latency (already mentioned in this thread here somewhere), but also (terminal / PTY) bandwidth throughput. This is three categories where 2 of the 3 are not related to "GPU acceleration" at all. :)

Stem0037 3y ago

I remember the days when I had to juggle between different emulators just to get a fraction of these features...

blueflow 3y ago

Prerequisites: ./scripts/install-deps.sh Please don't do this! List your dependencies normally. Packaging OSS projects is difficult enough already.

jraph 3y ago
I don't know. If the script is legible, that's an executable (and therefore probably tested), exact documentation. edit: yep, I just took a look and can confirm, it takes a few seconds to get the list of dependencies for several distributions. It's way better than most readmes.

czottmann 3y ago

> Available on all 4 major platforms, Linux, OS/X, FreeBSD, Windows I know it's nitpicky, but it's "macOS" since 2016, i.e. it stopped being "OS X" or "OSX" about 7 years ago.

tmtvl 3y ago

I like that they reference the VT510 manual, if the terminal implements the more advanced control codes then individual applications can do their work without needing to rely on their own implementations of the needed functionality. I'm gonna give Vttest a whirl in Contour and if it does well I'll try daily driving it for a while.

trapnii 3y ago
Please give us feedback in the issue tracker. We know we're not perfect, but certainly very much appreciate positive constructive feedback as well as bug reports. p.s.: I did not submit this link here, I intentionally try to avoid that, but I am surprised by the amount of people talking about terminals generally speaking here in this thread, even though a lot of comments (didn't finish yet) seem to be non-Contour related :)

deleted 3y ago

[deleted]

cmrdporcupine 3y ago

Looks nice, but seeming lack of tabs support (https://github.com/contour-terminal/contour/issues/90 https://github.com/contour-terminal/contour/issues/90) makes it a hard sell for me.

tupolef 3y ago

I just tried it and I will keep an eye on it for later. Currently it is a work in progress and there is a lot of issues with the dependencies and compatibility with legacy setups, but it is way better than Warp and other GPU terminals that I tried. I am currently a happy user of Urxvt and intend to continue until I am forced to switch to wayland (in a long time, I hope). In comparaison I have to add that the rendering in more defined in Urxvt that Contour even after tinkering, and like always it uses at least 5 times less memory.

trapnii 3y ago
> In comparaison I have to add that the rendering in more defined in Urxvt that Contour even after tinkering, Nothing is perfect. Many thanks for trying though. If you don't mind, maybe you could file a report in github.com/contour-terminal/contour/issues/ such that we know about it, can track it, and also, report back to you, once it's improved? Generally speaking, it's hard to say that rendering is that bad, because we simply use FreeType for glyph rasterization as well as Harfbuzz for text shaping. That doesn't mean it's perfect. I know that not everybody likes lcd subpixel rendering in Contour, and that anti-aliasing (AA) methods are generally highly subjective on what the best AA method is. We implement multiple such that most users should find what they like the most. If that still doesn't fit, I'd like to know about it, so we can hopefully fix it, just in case it is a bug on Contour's end. > and like always it uses at least 5 times less memory That's not a good metric to look at, at least it's not enough info to judge about. I recently read a guy comparing the memory resource usage of many terminals when having 2,000,000 lines of history configured and found Contour to be the winner here. This doesn't mean much though. I think just looking at the memory consumption is not enough to reason about it. I do agree however, that it should not blindlingly grow over time to something unreasonable. We try not to carelessly allocate any resource, so I'm pretty certain that we're doing "okay" in terms of RAM requirements.
- tupolef 3y ago
  I will find some time to write an issue about the rendering. And you're right, contour is doing okay in terms of memory, especially compared with other modern terminals. It's just that the first run after built uses already 250mb, and I think that when I will setup some fonts and run a few panes inside it will probably go higher. But if it stays around this number, it's really fine.

Conscat 3y ago

https://github.com/contour-terminal/contour/issues/382 https://github.com/contour-terminal/contour/issues/382 This apparently does not support the Kitty graphics protocol, just Sixel, which makes it look fairly unattractive to me, personally.

trapnii 3y ago
There are many reasons for me to not have kitty protocol implemented. Objectively speaking, I try to mention only one here: Sixel seems to have raised attraction across the whole terminal community over the past years and gets stronger adoption over other image protocols. Ah, and a second one: Kitty's image protocol is slow, purely performance-wise speaking. As an end-user that simply wants to cat an image, it probably won't be noticable, and our Sixel implementation isn't the fastest on earth either, but I welcome any contribution to Contour.
- aumerle 3y ago
  What nonsense. kitty's graphics protocol is literally infinitely faster than sixels for local transmission and the same speed as sixels for remote transmission, taking into account that kitty's graphics protocol supports 32bit colors, unlike sixel.
  - trapnii 3y ago
    This is interesting. I am trying not to feel offended by your toxic play, so let's get started: > kitty's graphics protocol is literally infinitely faster than sixels for local transmission Let's get the comparison right here (not apples with pies), Kitty graphics over the PTY wire is slower than Sixel over the PTY wire. Kitty supports bypassing the PTY by just referencing to a file locally present on the file system or using n SHM region on the local memory. Both solutions won't work over the internet, because they break the VT I/O model. But you are right, when bypassing the wire, it'll be faster. That sadly limits you to local-only use. > literally infinitely faster I wonder what your math behind this is :-P > taking into account that kitty's graphics protocol supports 32bit colors, unlike sixel Sixel is using a palette to define the colors to reference from. This pallete can be either in Hue or in RGB format. Of course, the palette has limited amount of entries (which can be queried), but during the image transmittion, just adjust your palette, to get a breader range of colors to chose from. It's still RGB, or to be more precise RRGGBB (8-bit red/green/blue components, which makes it 24-bit. I wonder if what you mean with 32-bit colors other than 24-bit colors plus 8-bit alpha. Alpha values is something that is not supported by sixel (wrong age for Sixels :D), but still it is possible to render images that do not cover only rectangular parts. For example that image here: https://contour-terminal.org/screenshots/contour-notcurses-ncneofetch.png https://contour-terminal.org/screenshots/contour-notcurses-n... - look at the logo. But I agree, semi-transarent images are not possible using Sixels. But then, you probably want to use a GUI then :)

politelemon 3y ago

Any idea why nvtop wouldn't work on it? I run nvtop and get "Error opening terminal: contour."

trapnii 3y ago
How did you install Contour and what is the TERM environment variable set to and is your terminfo properly resolved? I just asked someone with an AMD/NVIDIA card to try out nvtop inside Contour and it worked. So I assume maybe there is something fishy with your TERM/terminfo configuration.

muhammadusman 3y ago

Once in awhile I’ll try these new emulators but I keep going back to iTerm2. Maybe having a comparison of the two or similar would help convince me and others in the same boat.

fefe23 3y ago

I would love it if it became standard practice for projects to list their dependencies. I was going to try this but it wanted to pull in Catch2 (some unit testing framework) and apparently has a dependency on Qt. It is good and nice if your project has unit tests, and by all means use a framework if you think you need one. But don't make me install your framework just so I can do a standard release build. Only require it for building and performing the unit tests. If the home page mentioned the Qt dependency, I wouldn't have downloaded the source code.

da39a3ee 3y ago

I've in the camp of never noticed my terminal emulator being slow. Used iTerm2 for 10 years, switched to Alacritty recently for reasons unrelated to performance. Before iTerm2 on Linux I don't really remember what I used but I don't remember it being slow. Haven't noticed scrolling speed being slow, and I don't get this "insert latency" obsession.