Terminal emulators

yes
github.com/jwilm/alacritty
Rust wins again over C/C++

Fastest at what?
I don't even

At displaying gibibytes of text per second of course.

hey if it ain't broke, don't fix it

github.com/jwilm/alacritty/issues/289

My GPU is too weak for that. Too many pixels.

Attached: nfs_terminal_edition.png (787x367, 49.18K)

pseudo-realistic use of a fast terminal is games like Catacylsm DDA, they will genuinely lag in a slow terminal. Also I bet for half the faggots using gentoo here because of the meme, most don't realize that putting out all that compilation text actually slows down compilation. Yes, that's right, it's directly tied to the terminal speed. Try a faster terminal, or better do it --quiet

alacritty is a fucking mess written by people who don't know what they're doing, also it pulls like half of all rust libraries in existence in, I don't even wanna know how unsafe that is. All it takes is one compromised library.

Why don't you fix it yourself if it bothers you that much?

Found the anti Rust shill
jwilm.io/blog/alacritty-lands-scrollback/#benchmarks

Source?
About as unsafe as writing C/C++.

Looks like he wasn't faster than urxvt until Sept 2018. So go fuck yourself tard.

Source?
The anti Rust shill is immunized against all dangers: one may call him a LARPer, nodev, ctard, UNIX weenie, it all runs off him like water off a raincoat. But call him an anti Rust shill and you will be astonished at how he recoils, how injured he is, how he suddenly shrinks back: “I’ve been found out.”

right: per line of code

fucking hell this nigger doesn't even read his own garbage.

I read it. I'm just not sure that you have the mental capacity to understand was was written though. Alacritty v0.2 added scrollback support. This means v0.1 didn't have scrollback support.
If you wanted scrollback in Alacritty v0.1 you had to use tmux. So of course alacritty v0.1 loses against urxvt in a scrolling benchmark.
You anti Rust shills seriously are fucking retarded.

That's worthless then. Response speed, now that's a topic for discussion. Apparently, xterm is the fastest in that regard.

Attached: suckless_larpers.png (883x495, 16.29K)

git.suckless.org/st/

fastest response is direct console without X in between, you'll never get faster and it is kind of noticeable. I'm not even one of these retards that thinks he can notice 10 ms differences or hear the grass grow, but it does feel different typing there somehow.

What about keyboards though?
danluu.com/keyboard-latency/

xfce4-terminal

...

Attached: DeQcLi6WsAANp5u.jpg (710x532, 96.69K)

>>>Zig Forums

That's right kike. It seems mentioning White Man triggered you.

Attached: 56%.jpg (575x3110, 2.29M)

oh so he put it 3rd even though 0.1 couldn't even compete. Yeah sure thing faggot I'll trust your "benchmarks" now.

What you're saying makes no sense.

Scroll to the comments, st is the fastest if you bump some variables in its config.h.

xfce4-terminal is great.

...

Does a shell run directly within a terminal emulator, or is there yes another layer in between?

will not apply to most people here I'm guessing. I use kitty (also a GPU meme terminal emulator)--not because I find it superior to any other terminal emulator in terms of functionality (though I prefer my terminal UIs without extra menus and buttons), but just because it works on Wayland. It would probably run faster without its windows/tab shit but I don't give nearly enough of a fuck to go hunting for another terminal that works.

github.com/swaywm/sway/issues/2770
also there is this: lwn.net/Articles/465311/

Inside of an X session runs a terminal emulator (such as xterm), inside of which runs a virtual (pseudo)terminal (such as /dev/pts/0), inside of which runs a shell (such as /bin/bash), inside of which runs a consol program (such as /usr/bin/top).

Using callbacks to model the passing of time is for pajeets

Urxvt renders fonts incorrectly. I have no idea why and honestly don't give a shit why. A terminal that can't render text correctly is a failure.

Honestly they all suck. I use kitty at the moment but it happens to be written by a pajeet with an attitude worse than poettering.

I've noticed the consoles under GNU/Linux and OpenBSD don't implement many important ECMA-48 control functions that other terminals do. Examples include SCROLL UP, SCROLL DOWN, and CURSOR CHARACTER ABSOLUTE. These control functions make the screen seem to scroll up, scroll down, and move the cursor to a point on the current line, respectively.

The last can be discarded, but the former two are very important and I find it unacceptable that those consoles don't implement them.

If I'm wrong, I'd appreciate being corrected, but I've done my own testing and asking around and it seems these were simply never implemented.

I just use st.

Urxvt kind of lagged behind on verbose output, had subpar unicode support and did not support trucolor. Still, it is a pretty decent terminal emulator.

I would recommend st for minimalists, urxvt for functionalists and xterm for maximalists. Used a lot of emulator, and these still stand out as my standard choices.

How do I make my own?

I feel like there's still no AAA terminal available.

I use st because it's small and sanic fast and does what it needs to do
if I want a crufty terminal for some reason (like I need to cuntpaste a lot of stuff via ssh) I keep terminator around just because of the in-window-tiling but it's a slow cunt despite it's size (because python)

Just read the xterm souce code.

Well, urxvt lacks some stuff too. It doesn't support the invis termcap while st does.

I use terminology because it looks nice. Go ahead and bully me.

These retro feels are so comfy.

Attached: cool_retro_term.png (1123x750, 814.94K)

I just tried it, it has some neat stuff. I didn't find a way to save sessions though, like to remember splits.

this.
What program is that?

...

Yes.

same

I was actually going through a bunch of terminal emulators earlier today.
Here are my unsolicited reviews:

Attached: window manager tweaks.png (825x776 4.13 KB, 196.05K)

it's cool and edgy and all that, but I can't work in that.

Attached: cool retro term 3.png (1920x1080 2 MB, 2.85M)

Attached: cool retro term 4.png (1920x1080, 1.89M)

Attached: gnome terminal.png (739x487 16.48 KB, 70.41K)

Only hipsters who want to look 1337 and Kewl and don't know how to do anything other than install """Linux""" use this shit.

Wow, this dude is an ass.

HH
your dubs confirm

...

oh yeah it's probably shit allow me to use bloated modern garbage

those were all my posts though with all the screenshots.
I was really annoyed with all those term emulators btw and went straight back to xfce4

Found the rust shill

Found the rust shill

Correct

xfce4-terminal is really nice. Idk about how lightweight it is though.

I can't tell if you're calling "Cool Retro Term" bloated or calling other things bloated.

If it is the latter, you're retarded

pls
what? 3 bytes extra worth of memory?
come on
Yeah, I suppose your'e right
my processor might not handle it
it's from 1985

Attached: for real.gif (220x220, 196.93K)

urxvt cause i donno why not. it seems simple enough, and it provides a bg daemon which makes me feel smart

Most of you larpers probably don't even know you can set your own colors and fonts in pure linux terminal. I converted the fonts from int10h.org to .psf. They are incredibly readable, even on modern screens. I even made a batch of size x 2 fonts, they should have a nice size even on 4k.

The more steps you put between you and the console, the slower it's going to be. No matter where, always use bitmap fonts, never use these modern meme anti-aliased vector fonts, they're incredibly slow in rendering and because of the complicated way they're rendered, they're pretty much doomed to never line up pixel perfect. (try drawing boxes with the box characters with a font like Monaco or Iosevka, I'll wait, it'll look like shit) This is only possible with bitmapped fonts.

If you work directly from the linux console, tools like screen give you additonal VT100 control functions and things like scrollback. With screen you can also share sessions. I connect screen to a vt and use it to make printouts to an ereader with eink screen which is hooked up via usb.

There's so much possible without ever using a terminal emulator, there's really no reason to use one.

Linux console is a terminal emulator though. It's a virtual thing, instead of hardware device connected over serial port like was commonly used in the 80's and prior. Those terminals didn't emulate anything, they had their own set of escape codes for doing stuff like moving cursor around (assuming a glass terminal here, not a hardcopy teletype).
Pic is screenshot of LADDER.COM game for CP/M, in configuration mode. If you select the last option, it asks you to input the ASCII code sequences for clear screen, direct row/column addressing, and so forth. that your terminal uses The other choices are all commonly available (back then) real hardware terminals. The Linux console isn't like this at all, it was never available in actual hardware form, just some code in the kernel to drive the console, and it pretty much emulates VT100/ANSI more or less.

Attached: ladder.png (964x580, 24.49K)

True, that was a mistake on my part. With emulator I meant the X-based programs. They all have in common that they're a lot slower. They pretty much have to be as you have more layers in between what you press on the keyboard and what appears on the screen. If that slowless actually matters or not is the other question.

I find the virtual terminals in linux just work better and seem more compatible for my usage scenarios. The one that comes second in X is xterm. Everything else had some degree of problem for me, because of overwhelming slowness or incompatibility. Especially if you add more modern fonts into the mix in X.

There are also framebuffer terminals, but they all had in common for me that they're very slow, even though they have some nice extras. (YAFT for example has 256 colors and sixels)

sometimes i copy something in a program and i try to paste it in xterm with shift+insert and it doesn't paste what i had copied and that's why i always use konsole.

I'm a terminal noob, anyone want to spoonfeed?

just use tmux to split

Probably just autism, nobody notices the sub ms latency
If you use something like i3wm sure, but in a floating window manager it's just a lot faster to navigate between terminal windows with the keyboard, doesn't matter much if the emulator does that anyway since tmux is superior
Because those keybinds already have functions in the terminal, use ctrl+shift+c/v
Not really, if you don't have a busy background and don't set the transparency level up that high
Bloat

People buying into the speed meme are being baited. Most terminals are not bloated enough to actually be slow.
The real problem with terminals is how many stupid edge case failings they have. Try getting a terminal that displays UTF-8 correctly including CJK. Then one that doesn't fuck up vim in some way. Then one that doesn't fuck up tmux. etc.
It's really the perfect example of how shit everything is when people just go crazy and reinvent the whell for no reason over and over.

One of my computers is a Chromebook and the Linux terminal runs noticeably faster than any terminal emulator. Aside from that particular case though it probably doesn't matter.

Xterm is an excellent example of this. I'm disgusted with using Ncurses in a Common Lisp program, so I wrote my own terminal abstraction library; the intent was to permit me to manipulate a terminal at a high level using a lower library I've also written.
Here is the main page: verisimilitudes.net/2018-04-04
Here is the program itself: verisimilitudes.net/acute-terminal-control.lisp

I'll just be showing some of my comments.

With regards to extended colors, defined in ISO 8613-6 and how Xterm and others don't implement them correctly:

I have two functions, READ-EVENT and READ-EVENT-NO-HANG, that are intended to allow me to read events from the terminal at a high level, distinguishing between a mouse action, a function key, and normal character input, among other things.

The ECMA-48 standard defines a FUNCTION KEY control function and this scales to as many function keys as possible, but Xterm doesn't use this. Instead, it has multiple, incompatible schemes.

Xterm has multiple broken and incompatible mouse reporting modes and none of them are a proper control sequence and so none of them can be parsed nicely by a generic parser.

I've had a good deal of unpleasant interactions, because not only do these cretins not implement the standards correctly, they don't even know most of the standards they're implementing; they simply do whatever Xterm does. I spent too much of my time checking if ISO 8613-6 colors were the standard actually being implemented; I believe they are and it's simply done incorrectly. I submitted a lazy patch to the st developers and raised these issues, but no one really cared; I've similarly had no real luck with other terminal developers; I suppose the thinking may be that it would break too many programs, so we should all just use a subtly incompatible form of the standard instead. Where have you seen that before?

The only reason terminals are still popular is because everything else is even worse and now you can recognize that even that is truly awful and managed by idiots. I could write a much longer series of posts about this, but I won't.

pick one nigger

when we actually used those kind of screens, if we saw a screen like that we'd throw it out. Dial down those settings to achieve normality and it becomes a beautiful time machine into the past.

comfier settings, though too much bulge (the screens with that amount of bulge didn't use scan lines, and came earlier (late 70s) than those (mid 80s), and too much glare/halo on the letters.

They're all shit implementations of a shit concept. Right now I'm using mrxvt because its the only one that doesn't have a fuckton of input latency and other AIDS. I think it has an unpatched vuln but I rather kill myself at this point than play around with other terminals again.

I really don't miss CRTs, they gave me eye cancer. The only nice thing they had was this slight glow to everything, but tbh that probably caused half of the eye cancer. I have a used POS (Point-Of-Sale, not Piece-Of-Shit) 14" LCD screen here that does a similar glow because it has a vandalism-proof front that glares a lot. It has a CCFL backlight.

Everyone says LED back-light is the best and for power consumption I bet that's true, but even the highend LED-backlight screens I've seen are still significantly bluer than CCFL backlight ones.

The nicest for the eyes though is eInk. I have a 13" eink android tablet I use with Termux and screen as sort of secondary screen. Thing was crazy expensive. Sadly there's not a single solution on the market re: eink screen that doesn't suck balls. It's all the finest of chink engineering.

An OLED screen for a text based console would probably be amazing though, but they don't exist at usable sizes.

Examples of such incorrect font rendering?

(checked)
I personally like GPM myself for some things but I rarely use it.

Damn, this is life changing, now I can update my packages in 10.255 seconds instead of 10.26 seconds because there will be slightly less delay imposed by the terminal emulator, thanks Zig Forums.

a meme until you use terminals in fullscreen or a tiling manager, it helps break up the completely black terminal so there's a bit of noise on the screen, completely subjective and if not pseudo at worst
extremely useful for floating window managers and/or the user hasn't learnt tmux/screen
combination of bloated shell (sh, dash, bash, fish, zsh, etc.) and blaoted terminal emulator

speed is a bit of a meme but could be a huge difference and keybindings because ctrl+c kills the process, so some sane defaults have shift+ctrl+c

it's tucked away in the gui options and you can disable it, it's bloated but it werks
completely missing the point, it's in the name

If you're compiling stuff (i.e. Gentoo) the speed difference can be quite noticeable

...

...

Which is bloat since those multiplexers exist. Look at a dvtm/abduco for something better.
Are you retarded? sh is a standard, not an implementation and how is dash bloated?

Latency, not throughput.

Use parallel jobs, nigger.

It probably means screen is malfunctioning. I had an small amber CRT that I picked up in '97 that was old as fuck and started doing wonky shit and then it just died altogether.
But good CRTs were pretty smooth and stable, even if the dot pitch might sucks ass in some cases, but was still good enough for low resolution like the old computers used. Actually I even had my Amiga 500 hooked up to a 19-inch TV for several months, and it was fine that way. Just had to set Workbench to 60-columns instead of 80, then it was readable. I even used Deluxe Paint like thata and it was fine. The Commodore 1080 monitors were a lot nicer though.

Attached: Amiga-Workbench_zpsutk6gcxs.jpg (640x589, 89.62K)

Here is my setup. The terminal emulator is WSLtty, running on Windows 10, using the Windows Subsystem for Linux + Ubuntu. The font is Fira Code, which has neat programming ligatures and is already patched with powerline symbols. The programs being run are tmux for multiplexing the various shells, neovim for editing, and bash for the shell.

Attached: wsltty.png (2736x1744, 280.45K)