Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: Looking for a substitute terminal emulator. (Read 38320 times) previous topic - next topic
0 Members and 11 Guests are viewing this topic.

Re: Looking for a substitute terminal emulator.

Reply #30 –
Quote from: K0rpZ0uth – on
I would recommend giving st a try, though without some patching it's a bit spartan (I don't really care/mind), but there is an an accessible solution which lets you choose what features you need/want and leave out the cruft of what you don't need/want. Once you are finished I suggest using this cleanup tool to neatly wrap things up.

Did mine manually. There probably is a way to add ST patches that works fine. But I lack the knowledge to do it properly. Using the patch command didn't work for me.

Re: Looking for a substitute terminal emulator.

Reply #31 –
Where exactly are you failing? Does the first patch fail, or are you stuck on the second/third/etc., and don't know what to do with the .rej file?

Anyhow, Flexipatch (the ones mentioned by K0rpZ0uth as "an accessible solution") projects are there precisely so you don't have to effectively maintain a minifork of a suckless project yourself; thanks to how it uses preprocessor directives, code you don't want is stripped from the executable, so it generate minimal™ executables as the manual patching process would.

Re: Looking for a substitute terminal emulator.

Reply #32 –
Quote from: capezotte – on
Where exactly are you failing? Does the first patch fail, or are you stuck on the second/third/etc., and don't know what to do with the .rej file?

Anyhow, Flexipatch (the ones mentioned by K0rpZ0uth as "an accessible solution") projects are there precisely so you don't have to effectively maintain a minifork of a suckless project yourself; thanks to how it uses preprocessor directives, code you don't want is stripped from the executable, so it generate minimal™ executables as the manual patching process would.

For the former: (methods of building ST)
It's been a while. About a couple of months. So my answer will only reflect on what I remember. Some patches did not work (boxdraw). Yeah I have no idea on what to do with the .rej file. So I ended up having to look at the .diff file and see which ones to add/remove.
Using the patch command was a hit or miss for me. Sometimes it would not compile, and even if it did, I'd get a segfault. while doing it manually guaranteed the results. Although a bit of an inconvenience, it is what has worked for me.

As for the latter: (flexipatch)
For clarification, I simply stated that I did it manually with the reasoning included. Not arguing nor disregarding his (K0rpZ0uth's) suggestion.
And to add in now that I didn't knew about the flexipatch repo/fork until now.

Re: Looking for a substitute terminal emulator.

Reply #33 –
Just in case, these posts A look at terminal emulators in two parts 1 and 2 seem to reflect st (not sure if patched) is not that good on latency, it seems xterm is the winner.  Those two seem remarkably the same as 1 and 2.  That's 2018, but then there's this other post on 2024 Terminal Latency that seems to find the same without a patch, but then there's a re-generation of the tests on st with a patch (I don't see a reference for it) getting much better results, but still with xterm better.  st looks interesting in the amount of memory and resources required (some patches might notably change that I'd guess, like adding transparency and such), but the most appealing side of it is way less code (which again increases with patches), which xterm doesn't behave in this regard.  All in all, good old xterm is still rocking these days.  And yes, st with work seems able to improve, but it depends on one having to tweak it.

This topic, even though closed, has been really interesting to me.  Sorry for chiming in, and I appreciate the conversation.

@clappingsnowdrop, I did the edits because in the end having what I originally copied there was a misleading mistake, sorry about that.  Perhaps I didn't pay enough attention.  Just in case, alacritty is actually using the Mono version of Iosevka with just IosevkaTerm Nerd Font not sure why, that definitely influenced me, :)  And the nerd glyphs still show small regardles, like half the height, which is somehow weird, but I can still distinguish them so that's fine.  And having the Xresources settings specific to xterm and then copying them for uxterm just in case works, though not really required according to arch xterm wiki.  On another look, I decided to stick with IosevkaTerm Nerd Font Mono since when I'm tired it's easier for me to notice the difference between 0 and 8 with it, :)  Xterm settings are ok now I believe.  The xft when specifying the font is redundant when using faceName according to the man, but it doesn't hurt either.  If interested:

Code: [Select]
*.termName: xterm-256color
*.vt100.locale: true
*.vt100.utf8: true
*.vt100.utf8Fonts: true
*.vt100.metaSendsEscape: true
*.vt100.backarrowKey: false
*.ttyModes: erase ^?
*.vt100.saveLines: 4096
*.vt100.translations: #override \n\
    <Btn1Up>: select-end(PRIMARY, CLIPBOARD, CUT_BUFFER0) \n\
    Ctrl Shift <Key>C: copy-selection(CLIPBOARD) \n\
    Ctrl Shift <Key>V: insert-selection(CLIPBOARD) \n\
    Alt <Key>B: exec-formatted("xdg-open '%t'", PRIMARY) select-start() select-end() \n\
*.vt100.foreground:  #F8F8F2
*.vt100.background:  #000000
*.VT100.colorBDMode: true
*.VT100.colorULMode: true
*.vt100.color0:     #000000
*.vt100.color8:     #4D4D4D
*.vt100.color1:     #FF5555
*.vt100.color9:     #FF6E67
*.vt100.color2:     #50FA7B
*.vt100.color10:    #5AF78E
*.vt100.color3:     #F1FA8C
*.vt100.color11:    #F4F99D
*.vt100.color4:     #BD93F9
*.vt100.color12:    #CAA9FA
*.vt100.color5:     #FF79C6
*.vt100.color13:    #FF92D0
*.vt100.color6:     #8BE9FD
*.vt100.color14:    #9AEDFE
*.vt100.color7:     #BFBFBF
*.vt100.color15:    #E6E6E6
*faceName: xft:IosevkaTerm Nerd Font Mono:style=Regular:antialias=false
*.faceSize: 15
*.vt100.charClass: 33:48,36-47:48,58-59:48,61:48,63-64:48,95:48,126:48
*.vt100.pointerColor: red

This one:

Code: [Select]
*.vt100.charClass: 33:48,36-47:48,58-59:48,61:48,63-64:48,95:48,126:48

Makes it easy to match URLs and paths in the text with double click, but I'm debating if that's what I want because it breaks one word kind of default.  We'll see...

Re: Looking for a substitute terminal emulator.

Reply #34 –
I see, so there's no need to specify which terminal. Specifying vt100 is good enough. Thanks.

What I don't like about xterm is that the output is slow with the command of ls with colors set:
Quote from: clappingsnowdrop – on
Gave xterm a shot, configured it and it meets every requirement listed above, even the password hide prompt. But for some reason it's slow in output. About .002 ms per line of output from the command ls -lha (165 lines). Compared to all other terminals listed above where it's instantaneous.

Quote from: clappingsnowdrop – on
A more exaggerated test of 1000 files
Code: [Select]
touch file-{1..1000}.txt

urxvt
time ls -lhart

real	0m0.009s
user	0m0.003s
sys	0m0.006s

xterm
time ls -lhart

real    0m1.010s
user    0m0.006s
sys     0m0.006s


Using xterm + tmux slightly helps, but output is still slower compared to st + tmux.
Been trying out different xterm options, but no luck on my end.
 

Re: Looking for a substitute terminal emulator.

Reply #35 –
Just in case, on my side..

xterm
-------
real    0m0.012s
user    0m0.008s
sys     0m0.004s

rxvt-unicode
-------------
real   0m0.013s
user   0m0.005s
sys   0m0.008s

alacritty (just to compare)
---------------------------
real   0m0.010s
user   0m0.004s
sys   0m0.006s

Alacritty looks better but not for much, I mean pretty close.  I don't see the effect you notice on real for xterm.  Additional trials on xterm:

real    0m0.012s
user    0m0.005s
sys     0m0.007
------------------
real    0m0.038s
user    0m0.019s
sys     0m0.018
------------------
real    0m0.012s
user    0m0.003s
sys     0m0.009s
------------------

It seem pretty consistent.  On your posted xterm result I see the real value doesn't add up.  See in all other cases real = user + sys, and in the case posted that's not the case.  Could it be a singularity?

But this is not latency, rather throughput.  What st patches are you looking at?  I'm interest on what you find out with it, and what ends up being your choice.  On the Terminal Latency's post, a st contributor mentioned there's a balance between latency and throughput, and the OP there posted positive improvement, moving st 2nd place after xterm, meaning perhaps playing around with st one can get a good balance.

When having some time, to really take a look at the suggested st patches I will, but at a quick glance there were too many, and from the few I overlooked by their name, they looked sort of required, but again the list is huge for a quick glance, and it's hard to pick the ones which would improve latency (which by default is one of the worse if not the worst).

Re: Looking for a substitute terminal emulator.

Reply #36 –
Quote from: kixik – on
On your posted xterm result I see the real value doesn't add up.

st is compiled with both minimum and maximum latency set to 0
patches used: boxdraw, font2 and glyph wide support (one that is compatible with boxdraw)

This is a test in a folder with 10000 files.
xterm LS_COLORS set to empty:
Code: [Select]
LS_COLORS=''

$ time ls -lhart 

real    0m0.117s
user    0m0.030s
sys     0m0.049s

st LS_COLORS set to empty
Code: [Select]
LS_COLORS=''
real    0m0.200s
user    0m0.028s
sys     0m0.051s

xterm + LS_COLORS
Code: [Select]
LS_COLORS="*#=0;38;2;119;119;119:*~=0;38;2;119;119;119:bd=0;38;2;59;59;59;48;2;222;222;222:ca=0;38;2;24;24;24;48;2;255;94;86:cd=0;38;2;59;59;59;48;2;222;222;222:di=1;38;2;54;138;235:do=1;38;
2;24;24;24;48;2;222;222;222:ex=1;38;2;131;199;70:fi=0;38;2;185;185;185;48;2;24;24;24:ln=0;38;2;63;197;183:mh=1:mi=0;38;2;237;74;70;48;2;59;59;59:no=0;38;2;185;185;185;48;2;24;24;24:or=0;38;
2;237;74;70;48;2;59;59;59:ow=1;38;2;54;138;235;48;2;59;59;59:pi=1;38;2;188;151;4;48;2;222;222;222:rs=0:sg=1;38;2;222;222;222;48;2;188;151;4:so=1;38;2;24;24;24;48;2;222;222;222:st=1;38;2;222
;222;222;48;2;54;138;235:su=1;38;2;222;222;222;48;2;237;74;70:tw=1;38;2;222;222;222;48;2;100;167;34:*.Z=1;38;2;184;145;245:*.c=1;38;2;222;222;222:*.h=1;38;2;222;222;222:*.o=0;38;2;119;119;1
19:*.z=1;38;2;184;145;245:*.7z=1;38;2;184;145;245:*.au=0;38;2;230;127;67:*.bz=1;38;2;184;145;245:*.cc=1;38;2;222;222;222:*.dl=0;38;2;219;179;45:*.dz=1;38;2;184;145;245:*.gl=1;38;2;250;145;8
3:*.go=1;38;2;222;222;222:*.gz=1;38;2;184;145;245:*.lz=1;38;2;184;145;245:*.md=1;38;2;222;222;222:*.n3=1;38;2;222;222;222:*.nt=1;38;2;222;222;222:*.qt=1;38;2;250;145;83:*.ra=0;38;2;230;127;
67:*.rm=1;38;2;250;145;83:*.rz=1;38;2;184;145;245:*.tz=1;38;2;184;145;245:*.wv=0;38;2;230;127;67:*.xz=1;38;2;184;145;245:*.CR2=0;38;2;219;179;45:*.JPG=0;38;2;219;179;45:*.MOV=1;38;2;250;145
;83:*.NEF=0;38;2;219;179;45:*.PNG=0;38;2;219;179;45:*.aac=0;38;2;230;127;67:*.ace=1;38;2;184;145;245:*.aif=0;38;2;230;127;67:*.anx=1;38;2;250;145;83:*.ape=0;38;2;230;127;67:*.apk=1;38;2;184
;145;245:*.arj=1;38;2;184;145;245:*.asf=1;38;2;250;145;83:*.aux=0;38;2;119;119;119:*.avi=1;38;2;250;145;83:*.axa=0;38;2;230;127;67:*.axv=1;38;2;250;145;83:*.bak=0;38;2;119;119;119:*.bbl=0;3
8;2;119;119;119:*.blg=0;38;2;119;119;119:*.bmp=0;38;2;219;179;45:*.bz2=1;38;2;184;145;245:*.cfg=1;38;2;222;222;222:*.cgm=0;38;2;219;179;45:*.cpp=1;38;2;222;222;222:*.csv=1;38;2;222;222;222:
*.cxx=1;38;2;222;222;222:*.deb=1;38;2;184;145;245:*.dxf=0;38;2;219;179;45:*.emf=0;38;2;219;179;45:*.eps=0;38;2;219;179;45:*.flc=1;38;2;250;145;83:*.fli=1;38;2;250;145;83:*.flv=1;38;2;250;14
5;83:*.gem=1;38;2;184;145;245:*.gif=0;38;2;219;179;45:*.hpp=1;38;2;222;222;222:*.ico=0;38;2;219;179;45:*.ini=1;38;2;222;222;222:*.jar=1;38;2;184;145;245:*.jpg=0;38;2;219;179;45:*.lof=0;38;2
;119;119;119:*.log=0;38;2;119;119;119:*.lol=0;38;2;119;119;119:*.lot=0;38;2;119;119;119:*.lzh=1;38;2;184;145;245:*.m2v=1;38;2;250;145;83:*.m3u=0;38;2;230;127;67:*.m4a=0;38;2;230;127;67:*.m4
v=1;38;2;250;145;83:*.mid=0;38;2;230;127;67:*.mka=0;38;2;230;127;67:*.mkv=1;38;2;250;145;83:*.mng=0;38;2;219;179;45:*.mov=1;38;2;250;145;83:*.mp3=0;38;2;230;127;67:*.mp4=1;38;2;250;145;83:*
.mpc=0;38;2;230;127;67:*.mpg=1;38;2;250;145;83:*.nef=0;38;2;219;179;45:*.nfo=1;38;2;222;222;222:*.nuv=1;38;2;250;145;83:*.oga=0;38;2;230;127;67:*.ogg=0;38;2;230;127;67:*.ogm=1;38;2;250;145;
83:*.ogv=1;38;2;250;145;83:*.ogx=1;38;2;250;145;83:*.out=0;38;2;119;119;119:*.owl=1;38;2;222;222;222:*.pbm=0;38;2;219;179;45:*.pcx=0;38;2;219;179;45:*.pgm=0;38;2;219;179;45:*.png=0;38;2;219
;179;45:*.ppm=0;38;2;219;179;45:*.pyc=0;38;2;119;119;119:*.rar=1;38;2;184;145;245:*.rdf=1;38;2;222;222;222:*.rpm=1;38;2;184;145;245:*.spx=0;38;2;230;127;67:*.sql=1;38;2;222;222;222:*.svg=0;
38;2;219;179;45:*.swf=1;38;2;250;145;83:*.swp=0;38;2;119;119;119:*.tar=0;38;2;165;128;226:*.taz=1;38;2;184;145;245:*.tbz=1;38;2;184;145;245:*.tex=1;38;2;222;222;222:*.tga=0;38;2;219;179;45:
*.tgz=1;38;2;184;145;245:*.tif=0;38;2;219;179;45:*.tlz=1;38;2;184;145;245:*.tmp=0;38;2;119;119;119:*.toc=0;38;2;119;119;119:*.ttl=1;38;2;222;222;222:*.txz=1;38;2;184;145;245:*.vob=1;38;2;25
0;145;83:*.wav=0;38;2;230;127;67:*.wma=0;38;2;230;127;67:*.wmv=1;38;2;250;145;83:*.xbm=0;38;2;219;179;45:*.xcf=0;38;2;219;179;45:*.xml=1;38;2;222;222;222:*.xpm=0;38;2;219;179;45:*.xwd=0;38;
2;219;179;45:*.yml=1;38;2;222;222;222:*.yuv=0;38;2;219;179;45:*.zip=1;38;2;184;145;245:*.zoo=1;38;2;184;145;245:*.zst=1;38;2;184;145;245:*.HEIC=0;38;2;219;179;45:*.avif=0;38;2;219;179;45:*.
conf=1;38;2;222;222;222:*.cpio=1;38;2;184;145;245:*.divx=1;38;2;250;145;83:*.flac=0;38;2;230;127;67:*.h264=1;38;2;250;145;83:*.heic=0;38;2;219;179;45:*.jpeg=0;38;2;219;179;45:*.lzma=1;38;2;
184;145;245:*.m2ts=1;38;2;250;145;83:*.midi=0;38;2;230;127;67:*.mp4v=1;38;2;250;145;83:*.mpeg=1;38;2;250;145;83:*.objc=1;38;2;222;222;222:*.opus=0;38;2;230;127;67:*.part=0;38;2;119;119;119:
*.rmvb=1;38;2;250;145;83:*.svgz=0;38;2;219;179;45:*.tbz2=1;38;2;184;145;245:*.temp=0;38;2;119;119;119:*.tiff=0;38;2;219;179;45:*.webm=1;38;2;250;145;83:*.webp=0;38;2;219;179;45:*.xspf=0;38;
2;230;127;67:*.cache=0;38;2;119;119;119:*.class=0;38;2;119;119;119:*.sqlite=1;38;2;222;222;222:*.tar.gz=1;38;2;184;145;245:*.tar.xz=1;38;2;184;145;245:*.torrent=1;38;2;222;222;222:*.incompl
ete=0;38;2;119;119;119"

$ time ls -lhart

real    0m5.640s
user    0m0.043s
sys     0m0.075s

urxvt + LS_COLORS
Code: [Select]
real	0m0.106s
user	0m0.040s
sys	0m0.044s

st + tmux + LS_COLORS
Code: [Select]
real    0m0.189s
user    0m0.038s
sys     0m0.044s

st + LS_COLORS
Code: [Select]
real    0m0.421s
user    0m0.039s
sys     0m0.070s

xterm + tmux + LS_COLORS
Code: [Select]
real    0m0.194s
user    0m0.033s
sys     0m0.053s

If without LS_COLORS xterm is faster, but with it it is slower. Strange thing is that the gap is close if I use tmux.

Re: Looking for a substitute terminal emulator.

Reply #37 –
btw, my tests were all with:

Code: [Select]
% echo $LS_COLORS 
rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.7z=01;31:*.ace=01;31:*.alz=01;31:*.apk=01;31:*.arc=01;31:*.arj=01;31:*.bz=01;31:*.bz2=01;31:*.cab=01;31:*.cpio=01;31:*.crate=01;31:*.deb=01;31:*.drpm=01;31:*.dwm=01;31:*.dz=01;31:*.ear=01;31:*.egg=01;31:*.esd=01;31:*.gz=01;31:*.jar=01;31:*.lha=01;31:*.lrz=01;31:*.lz=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.lzo=01;31:*.pyz=01;31:*.rar=01;31:*.rpm=01;31:*.rz=01;31:*.sar=01;31:*.swm=01;31:*.t7z=01;31:*.tar=01;31:*.taz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tgz=01;31:*.tlz=01;31:*.txz=01;31:*.tz=01;31:*.tzo=01;31:*.tzst=01;31:*.udeb=01;31:*.war=01;31:*.whl=01;31:*.wim=01;31:*.xz=01;31:*.z=01;31:*.zip=01;31:*.zoo=01;31:*.zst=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.jxl=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.crdownload=00;90:*.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:*.swp=00;90:*.tmp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:

pretty much the default ones from eval "$(dircolors -b)" and on xterm colors get overwritten any ways with the the ones I previously shared, without screen (I use screen rather than tmux, but not on the testing) and with colors.

I'll try st eventually...  Are you going to keep one after your testing?  or you're still on it?

Re: Looking for a substitute terminal emulator.

Reply #38 –
Quote from: kixik – on
btw, my tests were all with:

Code: [Select]
% echo $LS_COLORS 
rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.7z=01;31:*.ace=01;31:*.alz=01;31:*.apk=01;31:*.arc=01;31:*.arj=01;31:*.bz=01;31:*.bz2=01;31:*.cab=01;31:*.cpio=01;31:*.crate=01;31:*.deb=01;31:*.drpm=01;31:*.dwm=01;31:*.dz=01;31:*.ear=01;31:*.egg=01;31:*.esd=01;31:*.gz=01;31:*.jar=01;31:*.lha=01;31:*.lrz=01;31:*.lz=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.lzo=01;31:*.pyz=01;31:*.rar=01;31:*.rpm=01;31:*.rz=01;31:*.sar=01;31:*.swm=01;31:*.t7z=01;31:*.tar=01;31:*.taz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tgz=01;31:*.tlz=01;31:*.txz=01;31:*.tz=01;31:*.tzo=01;31:*.tzst=01;31:*.udeb=01;31:*.war=01;31:*.whl=01;31:*.wim=01;31:*.xz=01;31:*.z=01;31:*.zip=01;31:*.zoo=01;31:*.zst=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.jxl=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.crdownload=00;90:*.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:*.swp=00;90:*.tmp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:

pretty much the default ones from eval "$(dircolors -b)" and on xterm colors get overwritten any ways with the the ones I previously shared, without screen (I use screen rather than tmux, but not on the testing) and with colors.

I'll try st eventually...  Are you going to keep one after your testing?  or you're still on it?

I'll keep both. None of them are as good as the foot terminal (for me). But it is what it is.

Re: Looking for a substitute terminal emulator.

Reply #39 –
Just in case, on this GH issue for blog Terminal Latency:  Measuring Terminal Latency with Typometer one can read some comments from an st contributor, and from the first one:

Quote
Regarding st, however, you should know that the latency is configurable, and by default it's adaptive between 8ms and 32ms.

Generally speaking, there's a tradeoff between latency and throughput/flicker.

The smaller the latency, the worse the throughput is (e.g. in cat huge.txt) because the terminal has to render more frequently, and the more flicker-prone it becomes, for instance when the terminal updates the screen before the application completed its "output batch" - which then requires another screen update once the output batch is complete, e.g. when holding page-down in auto-repeat in vim or less.

This behavior is not unique to st, but what is unique to st is that it's configurable, and can be adaptive.

By default it's adaptive between 8 and 32 ms, and tries to draw as soon as possible after the application-output batch completes, i.e. the terminal input becomes idle.

To disable the latency completely. i.e. draw as soon as the terminal reads anything from the app/KB, set minlatency = 0 (at config.h), and keep maxlatency non-zero. This would remove any latency in st itself, though there may still be some latency elsewhere - outside the control of st.

To set a fixed, non-zero, latency, set minlatency and maxlatency to the same value (in ms).

To set adaptive latrency, set the range via minlatency and maxlatency, which is in practice typically results in latency closer to minlatency, but can be longer - up to maxlatency, if the application output is slow. The default of 8..32 is on the conservative side, and one could instead use 4..16 or 2..4 or any other range they prefer.

And from the second one:

Quote
as of few hours ago, the default was changed to minlatency = 2

BTW, I've confirmed that one with commit f20e169a20f3ee761f7e09714f1d4c10916cf4c6:  improve latency for the default configuration.

Finally on its third comment:

Quote
I contributed some code to st over the years, including the configurable and adaptive latency code.

So those comments are from the same developer actually introducing the configurable range and the the adaptive latency code.  One can read about that on the same st sync documentation.  About the range itself it says:

Quote
This range has equal effect for both X events and unattended output; it doesn't care what the trigger was, and only cares when idle arrives. Interactively idle usually arrives very quickly so latency is near minlatency, while for animation it might take longer until the application completes its output. maxlatency is almost never reached, except e.g. during cat huge.txt where idle never happens until the whole file was printed.

For tmux users the additional patch not in master yet according to that same documentation application sync st-appsync adds on top of the st-autosync one already in master a functionality that allows the application on top of st to interact with it, getting even shorter latencies.  And the documentation indicates tmux supports it, so definitely applying the patch might help if using tmux.

All that said, I think:

    - If minlatency is 0, maxlatency should be higher than 0, otherwise one might end up with too high refresh rate
    - If minlatency is higher than 0, then if wanted maxlatency might be made the same value.  However there's no need because interactive idle is said to become near minlatency
    - maxlatency should not be too short (close to minlatency), because then displaying too many lines on terminal will experience too frequent refreshes
    - current minlatency value is 2 and maxlatency value is 33 on head of master (and I believe latest release as well but haven't confirmed).  That range seems in theory sensible to latency

With head of master and without applying the st-appsync yet it would be nice to experiments for both latency and throughput (lately associated to performance by the mesa GL based terminals) on:

minlatencymaxlatency
default (don't touch)default (don't touch)
default (don't touch)16
default (don't touch)4
0default (don't touch)
016
04
02
01
And then repeat the same but once the st-appsync is applied and using tmux (interactive latency testing is meant to improve).

Also, the  blog Terminal Latency:  Measuring Terminal Latency with Typometer concludes than the default minlatency=2 + maxletency=33 is already pretty good on latency, pretty close to xterm, and better than anything else.  Also it mentions that tweaking to minlatency=0 + maxletency=1 makes st become the latency winner with even less latency than xterm, but I suspect with a penalty on throughput, and not sure if worth it.  The blog author was only concerned about latency, not throughput so we end up not knowing about the optimal balance.

So I believe @clappingsnowdrop that by testing those values one might start to gey closer to a good balance between latency and throughput, and I'm tempted to say minlatency at 0 and default maxlatency might offer a good latency even without the 2nd patch that helps with tmux.  But only testing might tell.