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

161–170 of 223 posts

Re: St – A simple terminal implementation for X

#161

Post by floatboth »

aexaey wrote: post #86
ycmbntrthrwaway wrote: post #18

Earlier quoted context omitted.

Scrollback is implemented as a patch: http://st.suckless.org/patches/scrollback

This. Also, one should keep in mind that having to apply personal patches is perfectly acceptable for suckless software. In fact, for the very same st, to change font, colour scheme, or hotkeys/shortcuts - one has to edit config.h file and recompile. There is no traditional text config file or "Preferences" menu. This might sound bizarre at first, but actually works as well as editing a text config file: config.h is…

> to change font, colour scheme, or hotkeys/shortcuts

No, you don't have to recompile it. For shortcuts, sure, but I haven't used any st shortcuts besides font size +/-.

Colors can be changed via the shell e.g. https://github.com/chriskempson/base16-shell and the font is passed via the -f flag.

Re: St – A simple terminal implementation for X

#162

Post by hobarrera »

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.

Re: St – A simple terminal implementation for X

#163

Post by aexaey »

dhimes wrote: post #160
hobarrera wrote: post #157

Earlier quoted context omitted.

What I dislike about this, is that I have to manually track new versions -- rather than just have my package manager pull in new versions that read a `st.conf` file.

Also, I like different colors for different things. Production server terminals look different that staging server terminals that look different than development terminals.

As floatboth pointed out above, it is possible to use a shell script [1] to dynamically change terminal colour mapping. Add this as "LocalCommand" to appropriate "Host staging-foo" and "Host production-bar" sections of the ~/.ssh/config file, and you're all set.

[1] https://github.com/chriskempson/base16-shell

Re: St – A simple terminal implementation for X

#164

Post by onli »

davidgerard wrote: post #155
fiatjaf wrote: post #132

That xterm README is from 1991. I believe it has improved a lot since.

It is also, in practice, actively maintained and gets bugfixes. It turns out there are a metric buttload of obscure corner cases that do need to work right. Here's the changelog: http://invisible-island.net/xterm/xterm.log.html xterm is addressing a vastly broader audience than st.

Which btw was my problem with it when using st. Corner cases like using nano under ssh just plainly did not work. Or copying stuff from the terminal that got linewrapped, if I get that wrap as a linebreak in the copy buffer it destroys the password I just copied, making it hard to use pass.

Re: St – A simple terminal implementation for X

#165

Post by jsjohnst »

josteink wrote: post #102
nine_k wrote: post #49

Earlier quoted context omitted.

Likely they enjoy tinkering with hardware, so they just needed the serial line support themselves.

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.

Can you describe the scenario where you can't use screen but can use a terminal emulator with serial support? I've done a ton of work using serial (mostly routers and switches, but some other stuff too) and never found an instance where that didn't work.

Re: St – A simple terminal implementation for X

#166

Post by jsjohnst »

nine_k wrote: post #49
jsjohnst wrote: post #13

Earlier quoted context omitted.

I can't believe they added serial line support and not scrollback. If you're going to claim bloat, serial line support definitely ranks lower on priority than scrollback.

Likely they enjoy tinkering with hardware, so they just needed the serial line support themselves.

So why isn't screen or minicom a valid reason to "avoid bloat" in supporting a serial line interface and scrollback support natively isn't?

Re: St – A simple terminal implementation for X

#167

Post by jsjohnst »

josteink wrote: post #119
jstimpfle wrote: post #117

Earlier quoted context omitted.

What reasons are there not to use tmux over screen these days?

Plenty of reasons: Habits. Existing scripts. Muscle-memory. GNU/GPL over non-GNU/GPL. To mention a few. I've honestly not found a single feature in tmux which I need which isn't already covered (and imprinted in finger-memory) by GNU screen. On the flip side, I'd ask: What reason is there for a seasoned GNU screen user to bother switching from something proven, and which works?

Other reasons have been listed already, but if you're an iTerm2 user, another strong reason to use tmux over screen is the fact tmux can use "native windows" in macOS and you have deep integrations between the two. It's especially useful with remote tmux sessions.

Re: St – A simple terminal implementation for X

#168

Post by hiq »

Lapsa wrote: post #154
hiq wrote: post #103

Is there a full-screen mode? I often use it with gnome-terminal and the vim-goyo plugin, it's pretty neat.

using i3 win+F here

F11 does not work with gnome, I thought it was part of the Gnome DE and not implemented in gnome-terminal...

Re: St – A simple terminal implementation for X

#169

Post by davidshepherd7 »

nine_k wrote: post #116
otabdeveloper1 wrote: post #101

Earlier quoted context omitted.

> the generally accepted notion that Gnome Terminal is one of the slowest with output Really? Generally accepted by who? My unscientific personal tests show that Gnome Terminal is the fastest and lightest VTE.

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?

Re: St – A simple terminal implementation for X

#170

Post by davidshepherd7 »

Jillboy wrote: post #112
satai wrote: post #62

I can't help myself: suckless sucks. Lots of arbitrary limitations for the code, need to recompile instead of configuration, optimizing for a wrong usage scenario.

I find that most of their software is targeted towards beginner/intermediate hackers. Having to recompile /forces/ you to tinker with the source code. When I was learning how to code I would hack the shit out of my window manager (dwm), I learned a lot of C in the process. When you think about it that way, the "arbitrary limitations" on lines of code and everything else starts to make sense. I agree most of their stu…

emacs had a similar effect on me. Configuration is all in elisp so you can happily tumble down a rabbit hole of tweaking settings and find yourself learning all kinds of interesting lispy ideas.
Post reply on HN