> It would be nice if someone worked on actually improving the terminal experience.
Contour. Oh, sorry, I mean: To be honest? There are plenty of young terminals that work on that, it's not just Contour, but also WezTerm, foot, Ghostty, Warp, and Terminal.click (even though I am strongly against their architecture). Also Charm and Fig should earn an honorable mention.
> Selecting, copying and pasting text is still pretty awful
Use the vi-like normal mode in Contour and that should(tm) fix almost all of the above problems. At least I have almost never touched a mouse again on Contour since I've implemented modal input in Contour. Well, I use the mouse, casually for scrolling and procrastinating by randomly clicking around. :)
> (why is the cursor an entire block rather than a I bar?).
this is configurable in recent terminals
> Editing multiline inputs is awful.
this should be implemented by your shell or readline, in case you want to improve here. your TE has nothing to do with this except that it provides the tools to realize that on the screen :)
> Navigating history is so-so (even with McFly etc.).
This is the job of the shell/readline.
> Anything more complicated than left/right/up/down fails half the time and dumps control characters instead.
I really cannot related that claim to anything I am experiencing in my own life. Sadly.
> Why are terminals always stuck in the 70s? Can I get a modern terminal?
To be fair, they are not named "emulator" for fun and giggles. But I agree, not every VT sequence or semantic should be blindingly implemented. Especially the Unicode case on Terminals were always a fight against the historian terminal emulator developers. I asked myself why a lot on that matter. My theory? Because it potentially requires those existing terminals to fully re-write their core code base in order to be fully (as full as it gets) Unicode aware.
This is implemented by 4 terminals (Ghostty, WezTerm, foot, Contour). One bite at a time I guess. Let's just stay positive, we can't break the world! (Terminal.Click? You listening?) But we should certainly break here and there when it makes sense and also not blindingly implement the 70s again. The GUI has also good moments and can live next to the TUI ;)
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.
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.
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-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 :)
No, its only slower over PTY because the kitty protocol is transmitting images with higher fidelity, aka color accuracy. So if you want to compare apples to apples get sixel to transmit images with equal fidelity first. I'll go raise three generations of my family while you try to achieve that.
As for infinitely faster, that was obvious hyperbole. For local transmission, using shared memory to transmit RGBA data directly is going to absolutely crush serializing then transmitting over a pipe the de serializing. This is so obvious it doesnt even need to be stated. And the vast majority of image display and indeed terminal usage in general happens locally not remotely. Which is why the kityt protocol sensibly prioritizes that use case.
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 :)
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.)
Monomux is a terminal multiplexer that isn't a terminal emulator. Less featureful than tmux (therefore) but still the better screen. Read the "Why" section for a much better explanation. :)
I don't your name, pc86, is a real name, too. That's the life of them internet. So much about Pseudonym. So if already the very first statement is that questionable, how can I believe the rest you write had any truth?
That this may or may not pseudonymous is mostly a coincidence. I've talked about current (at the time) and past employers, I've posted my emails in comments and my profile before, my LinkedIn, used my first and last name separately, etc. This is not an anonymous profile by virtue of any effort on my part. I think just about every account - including my discord - is associated with my real identity and uses my real name.
The GP seems to use similar naming conventions for all their accounts. GitHub, HN, Twitter, are all "lhecker." It's a pretty standard naming convention - I'm pcopley on a ton of services. So I can see how it could raise an eyebrow when you get an aberration of that norm or habit or brand or whatever you want to call it. The simple (and honestly maybe even likely) explanation is just "it's not an anonymous account I just have a different username on discord." But if you're inclined to pick up a pitch fork every now and then it's easy to take that as some sort of nefarious act.
Besides what pc86 wrote: there’s a difference between ‘not a real name’ and ‘a fake name’. A dog is not a fake cat. Being a fake entails pretending to be the real thing, which ‘pc86’ - as should hopefully go without saying - is not.
I like. Please submit a PR and make Windows Terminal as fast as refterm, trivially speaking, 2GB/s, no slower than the unoptimized refterm. Just to quote you: simple.
Reading your post feels good, man. But your last sentence kind of bothers me. Why do you feel they are insulting you now? I think, if at all, someone else was, and kept doing, and still is, insulting them instead.
In the last paragraph I indicated that they never insulted me. The very last sentence is referring to the article and that I'm sad to hear that this is the case now for others. When I personally interacted with Microsoft that wasn't the situation I had at all. I had a good experience.
the part where "he" is wrong, is the part where he tells everyone that his reference software can be compared to a real terminal. You cannot compare shoes with towels, nor cats with a TV. The tiling renderer "he" wrote as part of the reference software to demo isn't that bad as a product (to some degree), but that piece of software is garbage, as it has zero use. And almost none of the techniques "he" brags about can be applied to a real terminal. I mean, I like being educated. But so far, noone of the internet fanboys "he" has, has so far ever provided a real product out of his reference software. Admitted, some people tried (just look around), but they all failed. I wonder why. Do you know it?
> the part where "he" is wrong, is the part where he tells everyone that his reference software can be compared to a real terminal
He very clearly states that his implementation is a terminal renderer.
> And almost none of the techniques "he" brags about can be applied to a real terminal
Elsewhere one of the people from the screenshots says "we implemented the same approach" because these techniques can be and have been applied. Both in Windows Terminal and, as I understand it, in every single modern terminal emulator.
No. No you're not. Because you keep shifting goalposts and ignoring inconvenient truths.
First you claimed that "almost none of the techniques "he" brags about can be applied to a real terminal".
To which I linked and quoted Windows Terminal team: "We actually took the same approach Casey suggested. A lot of terminals implement it that way."
Then you shifted the goalpost to saying "We should distinguish here between renderer and VT terminal backend."
To which I replied: he implements VT parsing and rendering.
Is it a complete VT parsing and rendering pipeline? No. Does it invalidate his approach? No.
And to put this into additional perspective, Windows Terminal was abysmally slow with no VT parsing, and with no color output to begin with. It couldn't handle most of Unicode, wide characters and dozens of other things.
And so on. Now it's "sickness", "plain garbage" and other stuff. Tell me, are you perhaps on Windows Terminal team? Because that's a fine if exaggerated example of their behaviour just a year ago. Now they are like "yup, we're doing exactly the same things that Casey is doing".
But wait, don't tell me. I'm definitely not going to engage in this useless thread any longer.
> No. No you're not. Because you keep shifting goalposts and ignoring inconvenient truths.
I still am. Please submit a PR to refterm to that implements the VT sequences I mentioned above, until then I must continue to believe that you just repeat what other people say, without using your own brain. Shifting goalposts is probably not the best wording here. I keep listing arguments.
> First you claimed that "almost none of the techniques "he" brags about can be applied to a real terminal".
>
> To which I linked and quoted Windows Terminal team: "We actually took the same approach Casey suggested. A lot of terminals implement it that way."
"Almost none" does not mean "none". What WT applied is related to the tiling renderer. And I am sure I said "isn't that bad as a product" with respect to that. But Cassay also said that such things are super basic (if you know about it).
> Then you shifted the goalpost to saying "We should distinguish here between renderer and VT terminal backend."
>
> To which I replied: he implements VT parsing and rendering.
>
> Is it a complete VT parsing and rendering pipeline? No. Does it invalidate his approach? No.
VT parsing and actually doing something based on it, how often do I need to write that until you do understand that (!?), are two entirely different things. VT parsing is done in refterm, because it's needed for SGR and CUP, obviously. But everything else is discarded. All the other VT sequences that are parsed are not interpreted. Again, Please implement the VT sequences I mentioned above in refterm, without degradation of refterms claims.
> And to put this into additional perspective, Windows Terminal was abysmally slow with no VT parsing, and with no color output to begin with. It couldn't handle most of Unicode, wide characters and dozens of other things.
You use Cassays wording here. I'm fine with that, WT was and is in fact still slow. Just fork it, and make it faster. You guys keep saying it's simple, it's easy, it's all proven numerous times. Yet noone of you ever provided a terminal that is implementing enough VT sequences to be taken serious. refterm is a joke, it's garbage, and simply harmful. Not to its entirety, certainly not, it prove a point on rendering speed (7000 frames per second in a terminal-like application). Ignoring the usefulness of such for a moment, the reason why this whole rant of Cassay and his demo program is harmful to the public is, because you keep blindingly following him. Without questioning, without thinking about it, because thinking costs energy, one could say. I do not know your true reasons, but I can just encourage you to try.
I HEREBY CALL YOU OUT! Please work on refterm, and proof your point by implementing:
1. DECSTBM, DECSLRM
2. SM/RM/DECRQPM
3. alt-screen
4. DL, ICH, IL
5. rectangular operations (DECCRA, DECFRA, DECRQCRA, ...)
6. SD, SU (respecting margins set by DECSTBM)
7. DECAWM correctly applied.
> Tell me, are you perhaps on Windows Terminal team?
I am not part of Microsoft nor their WT team. I do however know how terminals work internally, because I have implemented one. So I do know what I am speaking about here. I even took refterm very serious and looked into the source code and tried to learn from it. Again, I was already saying repeatively that there are some good techniques applied, and also has some architecturally good decisions. But this does not hold on the performance level when you actually start implementing more than just bling-bling SGR plus CUP. Ignoring DECAWM is also a damaging descision.
> But wait, don't tell me. I'm definitely not going to engage in this useless thread any longer.
Because I call you out? That's cheap. Please at least have the balls and react on the actual content of my post (the VT sequences): technically!. Until then I must just assume you are (amongst many), a sickness of the internet: just repeating what narcissistic influencer keep saying, yet knowing nothing.
He never claimed refterm was a fully working terminal ready to use. He said it was a renderer. The entire point of refterm was:
<casey> Windows Terminal is slow at rendering things
<microsoft> Yes, rendering is a hard problem worthy of a doctoral research project
<casey> No it's not, you literally just use a glyph atlas
<microsoft> You are naive
<casey> *writes refterm to demonstrate glyph atlas*
You keep complaining that it's not a fully working terminal. Casey, on the other hand, writes:
"These features are not designed to be comprehensive, since this is only meant to be a reference renderer, not a complete terminal."
Exactly. Therefore you cannot compare a renderers performance with some other that has a fully functional VT backend attached. The comparising result is meaningless. His renderer is good, but the VT throughput performance claims he makes are wrong. For that to be fair, he should not take shortcuts in functionality.
Hey; what do you mean by "force"? I mean, to me this reads like you don't want to see italic nor bold font in the terminal (due to lag of monospace support in that regard maybe).
But I think having the possibility of italic, bold, bold+italic in the TE is a very good thing. And if you do not want that I think Kitty allows you to just use another font then; please correct me here, but I think that is configurable. Bold text in the TE world is yet another heated discussion. Some people like it bold, some people like the color to be intensified instead when using `SGR 1` (which is responsible for making font intensified/bold).
> And if you do not want that I think Kitty allows you to just use another font then
Do you really believe that's reasonable? That I should stop using my favorite monospace fonts just because a terminal emulator doesn't let me disable italic variants of that font when other terminal emulators like Alacritty and foot do?
I don't think that's reasonable and so I stopped using Kitty. And no, I'm not gonna resort to fontconfig hacks or manually delete the italic otf/ttf files. I'd rather use a terminal that gives me choice rather than imposes it.
> Some people like it bold, some people like the color to be intensified instead when using `SGR 1` (which is responsible for making font intensified/bold).
Indeed, and the right solution is a config options, just as was done in Windows Terminal, since nobody is wrong: it's just a matter of preferences!
The right technical way of handling preferences is offering more choices to the users, with some sane default that will satisfy most users.
Personally, I love italics (I use vim and I want comments shown in italics, and I make an heavy use of bold+italics, cf https://github.com/csdvrx/indent-rainbow/blob/main/after/syn... ) but I would not want to force this option to people who don't want italics, for their own reasons that are none of my business (actually, if they reasons are good enough, it may cause me to change the default choices, but I would never remove the user freedom to make such choices in the first place)
IMHO that's the key difference between MacOS/iOS/Gnome/new school linux on one side (fewer freedoms) and Windows/KDE/old school Linux (more freedoms)
Contour. Oh, sorry, I mean: To be honest? There are plenty of young terminals that work on that, it's not just Contour, but also WezTerm, foot, Ghostty, Warp, and Terminal.click (even though I am strongly against their architecture). Also Charm and Fig should earn an honorable mention.
> Selecting, copying and pasting text is still pretty awful
Use the vi-like normal mode in Contour and that should(tm) fix almost all of the above problems. At least I have almost never touched a mouse again on Contour since I've implemented modal input in Contour. Well, I use the mouse, casually for scrolling and procrastinating by randomly clicking around. :)
> (why is the cursor an entire block rather than a I bar?).
this is configurable in recent terminals
> Editing multiline inputs is awful.
this should be implemented by your shell or readline, in case you want to improve here. your TE has nothing to do with this except that it provides the tools to realize that on the screen :)
> Navigating history is so-so (even with McFly etc.).
This is the job of the shell/readline.
> Anything more complicated than left/right/up/down fails half the time and dumps control characters instead.
I really cannot related that claim to anything I am experiencing in my own life. Sadly.
> Why are terminals always stuck in the 70s? Can I get a modern terminal?
To be fair, they are not named "emulator" for fun and giggles. But I agree, not every VT sequence or semantic should be blindingly implemented. Especially the Unicode case on Terminals were always a fight against the historian terminal emulator developers. I asked myself why a lot on that matter. My theory? Because it potentially requires those existing terminals to fully re-write their core code base in order to be fully (as full as it gets) Unicode aware.
Have a look here for a baby-step forward: https://github.com/contour-terminal/terminal-unicode-core
This is implemented by 4 terminals (Ghostty, WezTerm, foot, Contour). One bite at a time I guess. Let's just stay positive, we can't break the world! (Terminal.Click? You listening?) But we should certainly break here and there when it makes sense and also not blindingly implement the 70s again. The GUI has also good moments and can live next to the TUI ;)