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

St – simple terminal

st.suckless.org

Post reply on HN
Print view View original

71–80 of 88 posts

Re: St – simple terminal

#71

Post by chriswarbo »

glandium wrote: post #47
gcb0 wrote: post #36

Earlier quoted context omitted.

i always found screen splitting in the terminal when you have a graphical window manager kinda of silly.

I'd love it if there would be graphical frontend to tmux or screen. Something that would look very much like a terminal emulator, with tabs and splits, but backed by screen or tmux, whereby each tab or split window would be a tmux or screen window. And the awesome part is that when you're elsewhere, you could ssh in and attach to that tmux or screen session.

You can send commands to a running tmux session, eg. http://superuser.com/questions/492266/run-or-send-a-command-...

How far you take it depends on what you'd want out of such a tool. Simple "New Shell", "Close Shell" buttons would be easy; overlaying draggable partitions would be more effort, and less elegant, but still do-able.

Re: St – simple terminal

#72

Post by fake-name »

antirez wrote: post #62

Every software is a product, even if it is OSS and no money exchange is involved at all. There is a designer, and a final user. The idea of this product is that terminals don't need to scroll up into the past history, actually doing this well is one of the most critical aspects of a terminal as a good product for end users: retain history, do it reasonably when programs controlling the cursors are executed, don't get…

You're entirely missing the point. Scrolling is already broken if you use any terminal multiplexer (such as `screen` or `tmux`).

As such, having an additional, useless layer of scrollback on the client is both confusing and pointless, so they removed it.

Re: St – simple terminal

#73

Post by chriswarbo »

antirez wrote: post #70
chriswarbo wrote: post #69

Earlier quoted context omitted.

> actually [scrolling up] well is one of the most critical aspects of a terminal as a good product for end users You've clearly misunderstood the point st is trying to make. Not only is it not critical, it's a bad idea for a terminal to store and scroll history! Yes it's nice to have a history to scroll through, but other programs (screen, tmux, Emacs, etc.) are much better at doing that than terminal emulators are!…

That's why I addressed it in the POV of a product. It's basically subjective. IMHO the "terminal product" should have history handling included.

If you're thinking about a "terminal product" then why single out st's lack of history at all? That would be like claiming Excel lacks presentation capabilities. Whilst it's a true statement, presentation facilities are irrelevant to a spreadsheet; they're available in the PowerPoint component of the Microsoft Office suite, and they're designed to work together, so it's a complete non-issue.

Re: St – simple terminal

#74

Post by koverstreet »

humanrebar wrote: post #51

I like the idea of cleaning up legacy cruft. I'm not crazy about the way this project is going about it. My main issues: * ignoring C best practices: /* prefix macros, please */ #define MIN(a, b) ((a) * barely any comments /* ME: ...so it parses a string? Doesn't pretty * much every parser? Also, no prefix again. */ void strparse(void) { * Lack of overall project structure. Maybe some comments here would clear things…

Yeah, agreed, the code is somewhat gross (also, everything is global!) and the people working on it have poor taste in coding style.

I forked it awhile back, this is the terminal I use now:

http://evilpiepirate.org/git/st.git/

Re: St – simple terminal

#75

Post by vortico »

stormbrew wrote: post #3

> Some random program complains that st is unknown/not recognised/unsupported/whatever! I really wish there was a better way to deal with this (I have the same problem with rxvt-unicode-256color). I'm obviously not going to make install a graphical terminal emulator on some random server I'm logging into.

Put the following in your shell configuration.

  alias ssh='env TERM=xterm-256color ssh'

Re: St – simple terminal

#77

Post by mzs »

I actually use xterm's tek4014 emulation for plots, I can keep them going off to the side at 15Hz just drawing over the top of each other until I change something in the main text window, then I erase and repeat. I tried to do similar with gnuplot but I could never figure-out how to keep updating continuously like that, so that's why.

Re: St – simple terminal

#78

Post by farresito »

gh02t wrote: post #64
farresito wrote: post #55

The best terminal emulator I've used is termite[1]. It has vim-like keybindings and normal/insert mode, plus a bunch of other features worth looking at. If you are using xterm, urxvt, or something similar, I would highly suggest giving it a try. [1] https://github.com/thestinger/termite

Termite is lovely. If you like it, you might also want to look at ROXTerm.

I'm a tmux user, so the menus and tabs are not really useful for me :). And the command mode in termite is vim oriented, so it's quite nice. I'm not sure how ROXTerm does it. To be honest, as long as a terminal supports vte (for fontconfig), it's already a huge improvement over xterm and urxvt.

Re: St – simple terminal

#79

Post by e12e »

emilburzo wrote: post #25
e12e wrote: post #12

Earlier quoted context omitted.

I've been using a few - in the end I landed on sakura: http://www.pleyades.net/david/projects/sakura I don't quite remember why I ended up moving from urxvt to sakura (and not eg: roxterm) -- but I think it was a combination of it being light (enough), easy to set up without any kind of window decorations, as well as a sane way to pick and choose fonts. With the current gtk ~/.conf-scheme it has a nice ini-like confi…

Thanks for letting me know about sakura, I think it's the first one to actually match the rendering speed of xterm. I do have one question though, why are the colors more pale in sakura than in xterm? And is there any way to change it?

On my windoze box now, so can't check - but I think there should be something about colors in the right-click context menu? But I'm not entirely sure when (as in which version) palette/colorset support[1] was added -- it might not yet be in Debian stable?

https://code.launchpad.net/~kraiskil/sakura/colorsets/+merge...

Re: St – simple terminal

#80

Post by systems_glitch »

aartur wrote: post #33
psibi wrote: post #30

Earlier quoted context omitted.

> Linux kernel ships with drivers for very old devices and doesn't have plans for removing them. I think as long as there is someone to maintain that driver, it doesn't get removed.

But if removing them would simplify other parts of code, I think they would do it, like they did for i386 recently.

Indeed, they do remove truly unused architectures and drivers from the kernel -- support for IBM MicroChannel is gone, as well as support for "it was uncommon back then" hardware. I have a bunch of Allied Telesis ISA 10baseFL Ethernet cards that were recently removed.
Post reply on HN