/tech/ - Technology★

>>1018858 (OP)

termite

Used to be a yuge urxvt faggo but xfce4-term is the best I've used. Good balance of werks-n-features and minimalism.

xterm. Seriously.

No bugs, fast, works with everything, even has sixel support. It's the reference. Even on old systems the overhead it has compared to more incomplete emulators is not worth putting up with their problems. Use it with a bitmap font and that will be the fastest terminal emulation you can get.

>>1018872

                        Abandon All Hope, Ye Who Enter Here


This is undoubtedly the most ugly program in the distribution.  It was one of
the first "serious" programs ported, and still has a lot of historical baggage.
Ideally, there would be a general tty widget and then vt102 and tek4014
subwidgets so that they could be used in other programs.  We are trying to
clean things up as we go, but there is still a lot of work to do.

>>1018892

Yeah, it's a mess code wise, but it works and works fast. Compare st (which isn't well written either but meme here) to xterm in regards to speed. Hell, compare it to urxvt. xterm will come out on top.

>>1018893

>>1018893

>urxvt

Except urxvt is actually good

Why is the ancient terminal abstraction still a thing in current year?

>>1018895

Because making something better would require committing more resources than to just continue using the pile of shit that alreadt exists.

"If it ain't broke, don't fix it" is the real UNIX philosophy.

Gas all UNIX weenies tbh.

>>1018893

>speed

Is anyone seriously concerned with terminal speed?

>>1018897

yes

https://github.com/jwilm/alacritty

>Alacritty is the fastest terminal emulator in existence. Using the GPU for rendering enables optimizations that simply aren't possible in other emulators.

Rust wins again over C/C++

>>1018899

Fastest at what?

>rendering optimizations

I don't even

>>1018900

At displaying gibibytes of text per second of course.

>>1018896

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

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.

>>1018896

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

>>1018906

>posting 2 years old disinfo

Found the anti Rust shill

https://jwilm.io/blog/alacritty-lands-scrollback/#benchmarks

>>1018908

>alacritty is a fucking mess written by people who don't know what they're doing

Source?

>I don't even wanna know how unsafe that is

About as unsafe as writing C/C++.

>>1018915

>disinfo

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

>>1018921

>Looks like he wasn't faster than urxvt until Sept 2018.

Source?

>So go fuck yourself tard.

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

>>1018915

>about as unsafe as c/c++

right: per line of code

>>1018922

>Source?

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

>>1018926

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.

>>1018858 (OP)

http://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.

>>1018928

>terminal latency

What about keyboards though?

https://danluu.com/keyboard-latency/

xfce4-terminal

>terminal for the White Man

>>1018933

>my ebin shitpost is so ebin I have to redtext and greentext at the same time to show everyone how ebin my shitpost is

>>1018936

>calling everyone a kike

>>>/pol/

>>1018937

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

>>1018927

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

>>1018944

What you're saying makes no sense.

>>1018928

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

>>1018869

xfce4-terminal is great.

>overclocking a terminal emulator

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

>whatever default your distro comes with

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.

>>1019081

>using software by a pajeet that doesn't understand how callbacks work

https://github.com/swaywm/sway/issues/2770

also there is this: https://lwn.net/Articles/465311/

>>1019078

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

>>1019085

Using callbacks to model the passing of time is for pajeets

>>1018894

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.

>>1018930

>direct console without X in between

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.

>fast

>easy to maintain

>only has the features i use and want i to have

>good unicode support

>truecolor support

>fast at rendering images (i use terminal file managers)

>customizable in every aspect conceived

>written in c, a language i happen to program in.

>overall small footprint

>don't need tmux to tab since my wm does this

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)

>>1019303

Just read the xterm souce code.

>>1019302

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.

>>1021179

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

>>1021212

this.

What program is that?

>>1021303

<he can't read the image's name

Are you illiterate?

>>1021312

Yes.

>>1021980

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

>>1019085

Wow, this dude is an ass.

>>1021988

HH

your dubs confirm

>>1021991

>November 2, 2011

>>1021988

>cool

>retro

>term

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

>>1021993

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

>>1018915

Found the rust shill

>>1018915

Found the rust shill

>>1022005

Correct

>>1021994

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

>>1021993

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

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.

>>1022034

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)

>>1018872

>works with everything

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?

>why care about speed, it's already fast on a modern computer?

>why use splitting when you can just open it multiple times and use your wm to "split"

>why things like ctrl+c ctrl+v don't work

>why transparency is a big deal isn't it harder to read

>why some terminals take a long time to launch (sometimes 1 sec)

>>1022096

just use tmux to split

>>1022096

>why care about speed, it's already fast on a modern computer?

Probably just autism, nobody notices the sub ms latency

>why use splitting when you can just open it multiple times and use your wm to "split"

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

>why things like ctrl+c ctrl+v don't work

Because those keybinds already have functions in the terminal, use ctrl+shift+c/v

>why transparency is a big deal isn't it harder to read

Not really, if you don't have a busy background and don't set the transparency level up that high

>why some terminals take a long time to launch (sometimes 1 sec)

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.

>>1022096

>>1022106

>Why care about speed, it's already fast on a modern computer

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.

>>1022109

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

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: http://verisimilitudes.net/2018-04-04

Here is the program itself: http://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:

>The NIL should specify the default color space identifier specified in ISO 8613-6.

>Unfortunately, giving a default value for this isn't parsed correctly by any terminal emulators, it seems.

>So, it is omitted for now.

>It will otherwise shift the colors under many implementations.

>You'd expect something as simple as this to be done correctly, but it's not.

>See page 49 of the standard; if 2, 3, or 4, there's a second parameter followed by more.

>That second parameter is the color space identifier, followed by the actual color integers.

>This second parameter is erroneously ignored, however, in a way that probably won't ever be corrected.

>I'll be submitting bug reports to the terminal emulators.

>So, perhaps I'll be able to send the correct sequence in a year or two.

>The same page specifies that character #x3A, colon, may be used to separate these parameters.

>Since that's a ``may'', the semicolon is used; at least this simplifies the program.

>Some terminal emulators don't parse the colons correctly anyway, but I don't care about that.

>If you'd like to learn more about the blatant violation of standards, read The UNIX-HATERS Handbook.

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.

>As we already know, xterm is very poorly and barely designed.

>Xterm likes to make its own standards for things, even when standards already exist.

>Xterm then likes to implement real standards incorrectly.

>Why use FUNCTION KEY when you can use SS3?

>Xterm is like a retarded child and should be put down.

>Here's the pattern xterm uses for function keys one through twelve:

>SS3 P SS3 Q SS3 R SS3 S

>CSI 1 5 ~ CSI 1 7 ~ CSI 1 8 ~ CSI 1 9 ~

>CSI 2 0 ~ CSI 2 1 ~ CSI 2 3 ~ CSI 2 4 ~

>Simplicity at its finest, you see.

>With any luck, this garbage can be removed soon.

>>1022109

>>1022138

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.

>Now, if the sequences sent were sane, I wouldn't even need this COND.

>Xterm sends CONTROL SEQUENCE INTRODUCER, but with characters other than parameters immediately following it.

>I can only figure this is to aid parsing by allowing one to quickly figure out what the control sequence (if you'd still call it that) is.

>While that does aid parsing if you just want a poor job, it actually complicates comprehensive parsing, like this.

>I can't just have a loop reading in parameters and then at the end matching a single character or two to see what it is.

>I can't just then check to see if the number of parameters read in is correct for the corresponding identity.

>I can't just have a limit to keep out of an infinite loop; three would be a good limit here, currently, since nothing supported needs more.

>Instead, I need a different case for each and then I can do the parsing, which is still followed by other identifying characters.

>So, this could've been a beautiful function, I think, but the horrible design of xterm prevented that.

>Instead, this is a purely practical machinery and I can only think about how nice it would've looked if things hadn't been designed by idiots.

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.

>>1022139

>mouse

>terminal

pick one nigger

>>1021983

>>1021980

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.

>>1021212

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.

>>1018858 (OP)

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.

>>1019274

Examples of such incorrect font rendering?

>>1022144 (checked)

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

>terminal emulator speed

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

>>1022096

>transparency

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

>splitting

extremely useful for floating window managers and/or the user hasn't learnt tmux/screen

>why some terminals take a long time to launch

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

>>1021977

>Terminator would be good if it didn't have the extra bullshit below the top margin-

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

>Guake

completely missing the point, it's in the name

>>1022360

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

>>1018892

>a readme from literally decades ago

>>1022375

>a terminal emulator from literally decades ago

>>1022363

>>splitting

>extremely useful for floating window managers and/or the user hasn't learnt tmux/screen

Which is bloat since those multiplexers exist. Look at a dvtm/abduco for something better.

>bloated shell (sh, dash, bash, fish, zsh, etc.)

Are you retarded? sh is a standard, not an implementation and how is dash bloated?

>>1022360

Latency, not throughput.

>>1022366

Use parallel jobs, nigger.

>>1022420

>windows 10

>linux subsystem

but why

>>1022450

Maximum Pajeetness

>>1022405

>Use parallel jobs

lol you think I don't?

>>1022468

Well, why would you complain about terminal output if you do?

In Nano, how can I get control backspace binded? I want it to cut one word left like in normal text editors, but it doesnt want to recognize it. Control P works, for example, but that isnt very intuitive. Others suggested using ^?, ^h, and ^H, but none have worked. Anyone know? I got the syntax for lua to work, and its comfy. Just doing casual coding.

>>1022540

>this is what gaming has LITERALLY become

sage because powershell is master race

>>1022405

yeah sh and dash isn't bloated, but is an example of a shell.

>>1022450

>but why

I was Linux-only for 8 years, anon. I don't hate myself anymore.

>>1022540

Retro games in 50 years will have deliberate dead pixels and screen tearing.

>>1022540

Nobody cares about your realism shit you fucking autists. It's just a meme, people want an idealized version of the thing, not the whole thing warts and all. Who wants warts?

Do you also complain that 80s stations play only the good songs from the 80s, and that movies make characters seem more interesting than they would be irl?

>>1022728

Are you confused? Read the post again.

>>1018858 (OP)

I've been using urxvt in daemon mode for a while now. It's reasonably fast and lightweight, and works fine for me.

I tried st but I didn't like it. Lack of scrollback alone makes it not worth it, not to mention that in the end, it wasn't noticeably faster or lighter than urxvt.

>use tmux for scrollback

tmux is good for remote sessions, but it's effectively useless locally if you're already using a tiling window manager. And no, the console is not an option for me, as I'm currently working with graphical programs as well.

>>1018858 (OP)

I'm using st because unicode works great & it's good with Ranger image previews. Also I like suckless.

>>1022912

I can only read that in my head with his voice.

>>1022789

man 1 patch, retard. And urxvt lacks the invis termcap, it's retarded.

>>1023004

<And urxvt lacks the invis termcap, it's retarded.

Literally a non-issue, I already use unclutter anyway.

Does st have a patch for it? Isn't it bloat for a terminal emulator to have this?

st. It's fast enough. But still not as fast as just using the TTY. I wish I was less dependant on xorg and could use the tty more often, fucking webshit.

>>1023195

>just using the TTY

You mean what by this, just using the getty consoles, preferably without framebuffer but just in pure text mode? They are "virtual terminals" too, a true teletype would be something like an actual VT100, so what's the difference in the end if it's pure text getty, framebuffer getty, or a xorg emulator like xterm etc.?

What is the best terminal multiplexer? screen? tmux? how to get buffer scrolling (shift-pgup/pgdn) work properly in screen?

>>1023401

And why do only modified versions of screen (like the ubuntu one) support vertical splitting? It seems that with widescreens and all it would make a heck lot more of sense to split vertically than horizontally.

>>1023130

Please defend your non standard abandonware.

http://pubs.opengroup.org/onlinepubs/7908799/xcurses/terminfo.html

>>1023401

dvtm/abduco

>>1023402

This is just a feature of newer GNU screen. It was a patch, before.

st (suckless terminal). No question.

>realize that less blaoted terminals have extremely smooth scrollback

although not sure if most /tech/ niggers have high refresh rate meme displays but it's pretty fucking epic

>>1023415

make sure you configure it to have render at a high fps

abduco works fine but dvtm has some of the weirdest bugs. Like, if you got a bunch of text scrolling pretty fast in one panel, it'll disturb the others, stuff like that. I use screen, no idea if tmux is better or not but I'm used to it.

>>1023420

how do you use shift-pgup/shift-pgdn in screen without it also scrolling the region boundaries? i.e. how to scroll the buffer of just the currently active region?

>>1023423

You go into copy mode(CTRL-A [) it lets you move the cursor freely around and scrollback with pgup/pgdown. with space you start selecting text, and space again stops the selection. With CTRL-A ] you can paste your selection.

>>1023438

*CTRL-a not A

>>1023413

Protip: being "nonstandard' and abandonware doesn't make something bad.

>>1023485

Still, missing an important termcap is embarassing. When using sh, you don't have read -p, so it's kind of needed.

>>1023004

The termcap database is obsolete crap anyway.

There's no reason not to use the linux' virtual TTYs directly, even if you want to run X apps. They can coexist and you can leave the X-Server running. With DRM, switching should be instant. (Dunno about nvidia, don't have nvidia hardware anymore, could well imagine that their blob drivers shit the bed there)

I admit It's such a minor thing but I like especially that the TTYs allow you to switch the cursor on the fly with escape codes, they even have the half-height cursors. I've used that a lot in vim to visually make a difference between modes. I just found that most stuff just works in the TTYs, while the different X-based terminal emulators always have something that doesn't. Xterm does work the best of them all though, it also supports sixels now, which basically allows you to print pictures right in the terminal. If the virtual-ttys would support sixels then they would be perfect, you can convert and write pictures directly to the framebuffer with ffmpeg, but it's just not as straightforward and needs some care taken so they don't get overwritten by text.

>>1023488

Terminfo has the same thing.

>>1023494

>the TTYs allow you to switch the cursor on the fly with escape codes, they even have the half-height cursors. I've used that a lot in vim to visually make a difference between modes

please elaborate

>>1023417

>make sure you configure it to have render at a high fps

Good point actually, never thought of that. Is it a patch or just a variable in the header files? All found on that was people talking about how they could possibly limit the frame rate, not increase it.

Smooth scrollback in a visual or in a sense of technical accuracy?

>>1023543

It's in the header files

config.h

/* frames per second st should at maximum draw to the screen */
static unsigned int xfps = 120;
static unsigned int actionfps = 120;

Mostly visual, and does reduce input lag if I recall, but that's in the realm of like milliseconds.

>>1023543

It's nice since I use a 144Hz monitor and most terminals only update at either 30fps or 60fps.

http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.7.pod#I_use_Gentoo_and_I_have_a_problem

>There are two big problems with Gentoo Linux: first, most if not all Gentoo systems are completely broken (missing or mismatched header files, broken compiler etc. are just the tip of the iceberg); secondly, it should be called Gentoo GNU/Linux.

<For these reasons, it is impossible to support rxvt-unicode on Gentoo. Problems appearing on Gentoo systems will usually simply be ignored unless they can be reproduced on non-Gentoo systems.

Wew.

>>1024333

Lmao no wonder urxvt sucks ass when compared to st or xfce4-term.

t. gentooman

>>1024333

What if I am using the BSD binutils instead of the garbage nigger utilities? Would it be Gentoo BSD/Linux then?

>>1024340

kek I thought the same thing. It's even in the urxct man pages, at page 7 if I'm not mistaken.

That link made me unironically switch to st.

>>1024355

The developer is probably a nigger. Also, the warning and the "Reporting bugs" section in its entry in the Gentoo Wiki: https://wiki.gentoo.org/wiki/Rxvt-unicode is gold.

>>1024358

>Also, the warning and the "Reporting bugs" section in its entry in the Gentoo Wiki: https://wiki.gentoo.org/wiki/Rxvt-unicode is gold.

For something so short, I bet it really stings. Lol.

If you want to use one machine as a terminal connected to the other's ttyS0, should the serial cable be straight-though, or a null-modem (i.e. crossed-over) cable?

>>1025935

normally you must have rx and tx crossed, not straight if you go for an UART connexion. but ...that's actually a good question I might want to check this, between an AS/400 and a Wyse term to me it's just a DB9 UART that's enough, then crossed or not ...

'Intresting thread; still want to use my 800XL as an ASCII term, I might find a way to wire this and find the adequate software.)

urxvt, of course.

>>1018858 (OP)

GNU Emacs (M-x eshell) or xfce4-terminal.

>>1022390

>an os from literally decades ago

>>1018915

>Here's this terminal emulator written in rust; it's the fastest in existence because we say so and it's faster in the benchmark we wrote specifically to show that we have the fastest terminal which isn't questionable at all.

>by the way it's fast because it's written to use OpenGL and the GPU and not the CPU

>forget that the entire graphics stack is written in C/C++ and rust is doing nothing but interfacing with it

found the jew

>>1018858 (OP)

mlterm + fix ur fonts fagit

Suckless is dropping xft support for dwm and dmenu: https://lists.suckless.org/dev/1902/33214.html

Is st next?

Good. Xft sucks. Use bitmap fonts like a white man.

>>1026812

The irony is that xfonts are an even worse mess than xft. I'll just switch to something that actually aims to be usable instead.

>>1026812

What is a "white man"?

>>1026804

If that means implementing a simple fallback mechanism, I'm all for it.

Fonts are so good that I often have no idea why characters won't display or what font I'm even using because I'm too scared that guessing will fuck up and I'll have crap fonts again.

>>1026849

st already supports fallback.

>>1027004

It doesn't, fontconfig does. If they remove it, they'll need to implement it themselves.

Termite is nice. Easier/cleaner to configure than .Xresources, has some cool built-in features like ctrl-shift-x to put hints by links so you can open them from the keyboard. Good for irc.

>>1022139

>>1022138

You. I remember you.

Is this xterm faggotry independent from the Linux tty subsystem? Or is that fucked too? What if someone were to make a new terminal emulator that implements the standards right? What if someone made a new standard?

>>1023183

Try some unicode shit. Screenshot the results.

>>1026622

>execute kitty

>GPU power usage jumps from 7 W to 30 W

GPU terminals are a mistake.

>>1018858 (OP)

what the fuck is that janky ass font about?

>>1026804

It's a good thing i didn't fall for the full suckless suite. I only use st and dmenu.

>>1027668

It's sad because, despite suckless fags being massive pretentious faggots, dwm is a legitimately good piece of software, in terms of its core functionality.

But deliberately *removing* existing, already implemented features from future releases just because they are "a mess" is just overcomplicating things for no gain.

It's already tiny, much smaller than even st. There is really no point in dropping a widely used font standard.

>>1027827

Just maintain your own version and merge their improvements into your fork.

>>1028345

<lel just fork it if you don't like it

You sound exactly like the trannies who wrote the Linux CoC.

If they stop displaying non-ancient fonts, I'm just gonna kiss st bye bye and use a working terminal emulator instead.

>>1018897

Yes.

The more niggerlicious terminals are so bloated they have input lag and so much overhead they can actually make a visible difference in how fast terminal programs run.

>>1022912

It's a name that describes the software perfectly, isn't it? Good enough.

>>1024333

>>1024340

urshitvt segfaults when I try to run it on my gentoo install.

>>1028355

Are you talking about daemon mode? For some reason, it needs Perl support compiled in to work correctly. I noticed this issue on multiple Linux distributions, including Gentoo. If not, when does it happen?

>>1028357

Not talking about daemon mode, but it does complain about perl now that you mention it.

Says it didn't find the extension "clipboard" even if I edit out the lines referencing the extension and reload the .Xresources

>>1028350

>complaining about maintaining changes to a minuscule source file

You might as well just kill yourself then, luser. Hope they drop your shitty fonts.

>>1028350

You use dwm/st and don't know that you use patches if you want additional features?

>>1028361

Niggers don't care about principles, as usual.

I honestly don't want to support unfinished software when working alternatives exists.

Sorry that triggers you so much.

I'm trying to migrate from st to xterm (image rendering is broken on st, at least for me) but I have 2 issues.

simpleterm displays bold characters with the brighter 8-15 colors, xterm also does, but it doesn't every time.

when I open vim with from simpleterm the theme uses the darker 0-7 colors, but when I open vim from xterm the theme uses the brighter 8-15 colors.

These 2 issues manifest with other programs, for instance neofetch from simpleterm uses the brighter colors for the distro logo ASCII art, and from xterm it uses the darker colors.

What the fuck is going on? I'm sure it's some xterm attribute I have missing, but I can't find it. I want to replicate the behavior I had with st on xterm.

>>1028365

Go use your gnome terminal then, luser. And stop complaining, nobody gives a shit about your complaints.

>>1028364

Doubt this kid can even apply a patch.

>>1028386

>download diff file

<run patch

>done

Wow, so hard.

>And stop complaining, nobody gives a shit about your complaints.

You've been replying to him until now, I guess you kinda do give a shit.

>>1028385

st fucks up images for me as well. They blame it on w3m, but there has to be something else going on, as it works fine in every other terminal emulator I've used.

>>1028385

I managed to fix the issue. The vim part is because vim somehow correctly detects the background is dark and uses the lighter color range when using xterm, whereas when using st it doesn't, and defaults to dark, which means the text itself is light. Vim simply happened to behave like I wanted previously. I wanted a dark background with a dark theme, because it's better on the eyes.

The boldness thing can be replicated under xterm with some trickery that I eventually figured out.

If you're struggling with theming, I recommend you use my theme. The st header is nothing complicated, I just wrote in colors and a font. The .Xresources is xterm made to behave and look like st does under my configuration, which again is the defaults + colors/font. The only issue is that the text is slightly bigger on xterm because both terminals handle font sizes differently, st picks font size by pixels, xterm doesn't.

You'll need this font https://github.com/nathco/Office-Code-Pro

.Xresources is at: https://paste.pound-python.org/raw/jXcDzxPrDRIP9O6nQPol/

st 0.8.1 header at: https://paste.pound-python.org/raw/Zzhh4ggV059A87fo2qRj/

The theme is pretty simple, it's almost exactly the default set of colors every terminal uses, with a 100% black background, and light grey (#ababab) text. I just wanted something that doesn't burn my eyes.

When you get down to it, the terminal situation is terrible, isn't it?

They all fail at something. xterm can't do unicode properly because it doesn't use fontconfig and can't fallback on fonts. Unless your font supports every character even if just the ones you're likely to run into (not even noto does) it's going to not display something.

st breaks with images, and also some unicode glyphs.

When I mention "some" unicode glyphs I exclude the universally broken ones like arabic, I'm talking about chink characters that fail to render and emojis which like it or not retards are going to insert into software or talk with over irc rooms.

rxvt is in theory xterm but fixed, however in practice it's xterm but even more broken, plus perlshit bloat.

And then once you get into the DEshit terminals they're all pajeetshit so bloated they manage to take a few hundred megabytes of RAM and require a gigahertz CPU.

>>1028684

Yeah... problem is, people who want to "do things properly" often refuse to include useful features (plus most people use DE terminals anyway). I actually used to use some light terminal for most open terminal-do thing-close terminal uses and konsole for writing code, because it has some features that are quite useful (ligatures for fira code, it handles cursors properly, url highlighting...). Though now I usually have enough resources to not have to worry about them and since I use KDE, I might as well use konsole for everything.

>>1028684

Xterm is the root of the problem. It's buggy garbage, doesn't follow standards and retards writing code to control the terminal targeted its bugs instead of fixing the xterm situation.The result is nobody really understands what the fuck a terminal even is anymore. Some programs hard code xterm codes and other shit, others use terminfo and the whole thing is a literally unfixable mess. The only way to fix it is to trash literally everything and start from scratch.

>>1028684

>And then once you get into the DEshit terminals they're all pajeetshit so bloated they manage to take a few hundred megabytes of RAM and require a gigahertz CPU.

Kitty literally causes a power draw of 20 W on my system due to its GPU acceleration.

>>1028684

It's all the fault of UNIX.

I'm waiting for the multics-fag to appear

No but seriously, it's all broken. Is there even anything that works without you having to fight your machine half of the time?

>>1028715

https://linusakesson.net/programming/tty/

>>1028757

Yeah I've read that article.

>In the UNIX world, the approach was to let the operating system kernel handle all the low-level details, such as word length, baud rate, flow control, parity, control codes for rudimentary line editing and so on.

>Fancy cursor movements, colour output and other advanced features made possible in the late 1970s by solid state video video terminals such as the VT-100, were left to the applications.

Yep. Even the motherfucking kernel hackers aren't up to the task of maintaining the tty subsystem in the kernel. I've read emails where they literally walk out on Linus after becoming too buttfrustrated by this tty shit.

But even that is less shitty than the user space terminal emulators situation. Because they're terminal emulators but do a shitty job at emulating anything. And applications start to rely on the shittiness. And other new emulators start emulating the SHIT instead of fixing it!

>>1018895

Because teletype machines are expensive and rare and cost money to operate?

Because they are compatible with software going back decades?

Are you retarded?

>>1019295

Just use screen or tmux, then you have unlimited scrollback.

>>1023649

I think most terminals update as fast as they run, and aren't fixed at a certain refresh rate.

>terminal emulators

>why learn the actual thing when you can learn many different languages that serve no purpose other than try to translate themselves into the first one

Where can I get a vt100?

I'm using xterm because of sixels support. That, and relatively fast opening speed on my slow machine. Konsole is much slower to open.

>>1029040

You would like to attach a literal vt100 to an UART and operate your system via /dev/ttyS0?

>>1024333

Fuck them - using st anyway.

>>1024358

>Reporting bugs" section in its entry in the Gentoo Wiki: https://wiki.gentoo.org/wiki/Rxvt-unicode is gold.

TopKek

>>1026489

This one never does what it should. I have to honour tge idea behind your post though

By the way, how do I get powerline fonts to work in any of them (preferrably st though) on gentoo? I wanna try out the spacemacs config files but it looks like shit when all the glyphs are missing. It's literally the only thing that doesn't work yet.

>>1029829

>Download and install a patched font (from https://github.com/powerline/fonts)

>in st/config.h change the line char font[] = .. to "Your Font for Powerline:pixelsize=12:antialias=true:autohint=true"

>sudo make install

this relies on fontconfig, naturally

>>1028423

>>1028423

It works fine in everything but st? really? That's kinda strange. On my machine it seems that st fucks w3m img up the 2nd least. It's only perfect in framebuffer mode. On Arch. On Gentoo, w3m doesn't seem to support fb mode.