Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

St – A simple terminal implementation for X

st.suckless.org

Post reply on HN
Print view View original

201–210 of 223 posts

Re: St – A simple terminal implementation for X

#201

Post by swinglock »

cuckcuckspruce wrote: post #200
josteink wrote: post #102

Earlier quoted context omitted.

With serial support, you definitely want scrollback, since you can't run GNU screen (or tmux for the hipsters) during a HW bootsequence. It absolutely seems like very conflicting decisions user-experience wise.

You can absolutely run GNU screen during a HW boot sequence through serial. See the Windows Types[1] section of the GNU screen manual. [1] https://www.gnu.org/software/screen/manual/html_node/Window-...

But if you're going to use screen to connect to your serial port, what was the point in adding serial to support to the terminal emulator?

To make the argument that scrollback is bloat is insane if you at the same time add serial support but need scrollback for serial usage, so you use screen instead which had both serial support and scrollback.

Re: St – A simple terminal implementation for X

#202

Post by steveklabnik »

pmoriarty wrote: post #188
wruza wrote: post #81

Earlier quoted context omitted.

Last time I asked, someone said: "many features, but I like cmd-click to open path". After reading [1] I see that all it does is loading hipster-oriented "features" into your brain. Almost every feature is useless if you're doing any amount of actual work with decent cli tools. But for playing a hacker it is pretty cool. [1] https://www.iterm2.com/features.html

I don't know if the "cmd-click to open path" is a feature that's already built in to any Linux terminal (though I wouldn't be at all surprised if it was, considering how many terminals Linux has). You can probably do something like it with urxvt's perl extensions. You could also just double-click to copy the path to the X primary selection and then use a keyboard macro to open the path in the primary selection in you…

On my pretty stock debian system, my terminal in i3 does the cmd-click bit.

Re: St – A simple terminal implementation for X

#203

Post by mlichvar »

davidshepherd7 wrote: post #169
nine_k wrote: post #116

Earlier quoted context omitted.

You can run a completely unscientific experiment yourself: take a really large text file, or just use `yes`, and time its full output on several different terminals. yes | head -n 1000000 > two_megs.txt time cat two_megs.txt You will definitely see a difference in the time it takes to complete or a libvte-based terminal, xterm, urvxt, roxterm, etc. OTOH I can google up posts saying that pt shows good results in compa…

Huh, interesting results on my machine: urxvt 0.233 gnome 0.474 st 0.515 xterm 1:13.87 times are total real time, in seconds, seem repeatable from a few runs. I was expecting st to blow everything else away given its focus on minimalism, and what the hell is going on with xterm?

xterm is showing all data. That's why it's slower. For a fair comparison, you should set the fastScroll X resource, which will allow xterm to suppress screen refresh.

Re: St – A simple terminal implementation for X

#204

Post by abjectcircle »

hobarrera wrote: post #162

st lack support for a fallback font, so I can't have emoji on my terminal, and that really breaks my workflow because I'm sure I'll eventually need to see an emoji on the terminal for some reason, so I've dedicated hours tweaking this just to be ready for that moment.

This should be accomplishable by tweaking fontconfig.

Re: St – A simple terminal implementation for X

#205

Post by billiob »

mxvzr wrote: post #194
billiob wrote: post #89

Earlier quoted context omitted.

(main developer of Terminology here) As stated on https://phab.enlightenment.org/T746 , it is not an easy move due to the way the text grid is designed. I might work on it someday.

unrelated: are you the billiob that used to contribute to aMSN back in the days?

Yes, I am!

Re: St – A simple terminal implementation for X

#207

Post by smlacy »

chrissnell wrote: post #28
smlacy wrote: post #2

Why do people care so much about terminal emulators and their supposed "bloat" and "complexity"?

Bugs. When you work all day long in a terminal, you need it to be reliable. As I mentioned above, xfce4-terminal is what I normally use but select-to-copy doesn't work 100% of the time. This is super annoying. I'd switch to rxvt but it has its own problems. Despite having had terminals for so much longer, *nix has fallen behind macOS when it comes to terminal usability and reliability.

I work literally all day long in multiple fullscreen gnome-terminal instances, and I can't remember the last time I encountered a "bug". It literally never crashes, and works perfectly for my use case.

I can imagine there could be bugs in esoteric terminal emulation, but for the typical use case of "TERM=xterm-256color" (or screen-256color) it works perfectly for my use case.

Re: St – A simple terminal implementation for X

#208

Post by smlacy »

chriswarbo wrote: post #113
smlacy wrote: post #2

Why do people care so much about terminal emulators and their supposed "bloat" and "complexity"?

The way I see it, st is trying to replace xterm. xterm is a de facto standard, in that you can sit down in front of a machine which appears to be running some flavour of Unix, it doesn't matter if it's Gnome, KDE, TWM, CDE, etc., GNU or BSD or Solaris or whatever, you'll probably be able to find xterm and work out the rest from there. Many devs/hackers use xterm as their day-to-day terminal, and seem to approximate A…

- I dispute "many devs/hackers use xterm". I switched away from xterm over 20 years ago, when it was clear that they were never going to have good support for anti-aliased fonts. I work heavily in the linux and with linux devs, and I can't remember the last time I saw someone using an xterm on a modern system.

- xterm is for exactly the case you describe: when all you have is "base X11" and you need a terminal. No crazy multi-gigabyte toolkit requirements. Its essentially a fallback/recovery tool for these cases, although I prefer just working on console when things get that bad.

- xterm's codebase is 30+ years old. "unmaintainable" seems like an overstatement, by a longshot.

Re: St – A simple terminal implementation for X

#209

Post by smlacy »

charlesetc wrote: post #4
smlacy wrote: post #2

Why do people care so much about terminal emulators and their supposed "bloat" and "complexity"?

There have been many times when vim starts glitching out or something because of the terminal emulator I'm using. Even well tested ones like X-term and gnome-terminal. I never had that problem using st. We hack so much into a text interface it's really easy to accumulate bugs.

I use tmux+emacs inside gnome-terminal for 8+ hours a day.

I rarely (never?) see any "terminal glitching" except for the cases where I've done something absurdly wrong, like running a bash inside emacs-shell with the wrong setting for TERM.

Terminal emulation is essentially a solved problem (state machines and control code sets are small and well defined, there are many reference implementations and compatibility tests). If you see glitching, it's probably from what you're doing inside the terminal, not from the terminal itself.

Re: St – A simple terminal implementation for X

#210

Post by smlacy »

Karrot_Kream wrote: post #100
smlacy wrote: post #2

Why do people care so much about terminal emulators and their supposed "bloat" and "complexity"?

Not everyone has the latest and greatest machine.

Are you saying that xterm has poor performance?

This appears to be true (from other comments on terminal performance in this thread) but other VTE-based terminals (gnome-terminal) have high performance and work great on sub-1GHz class machines.

Post reply on HN