St: Simple terminal implementation for X | Hacker News Reader

St: Simple terminal implementation for X

st.suckless.org

91 pointsamarsahinovic39 comments

fonts (you can use xfontsel(1) to generate a valid XLFD)

No no no no no. Stop using core X fonts. Just... stop. If this is supposed to be a "modern" replacement, it should be using fontconfig and client-side fonts with an appropriate renderer.

That's really not the Suckless way. It is hard to really describe in a nutshell, you should just check out their philosophy page: http://suckless.org/philosophy

I guess the best way to describe it is they are along similar lines as the 'cat -v' folks.

I get that using client-side fonts adds dependencies and complexity, but XLFDs are not "simple"... for the user, anyway.

I dunno. The Suckless guys may feel that simplicity of implementation is king; I believe that simplicity for the user is more important. Each to their own.

I don't believe the suckless team is working with the same definition of "modern" as you might be.

Some of us prefer bitmapped fonts, even on high-resolution displays, and software with fewer dependencies. There are some nice high-resolution bitmap console fonts in the standard X font collection, and others (Terminus, Proggy) are readily available.

That's definitly the right direction. Our software stack is getting too complicated, and is carrying so much stuff that is almost never used (e.g. obscure entries in terminfo's db). But of course, real world does not give us much time to rethink/refactor our computing structures.

Maybe people will start to refactor the worst offenders. It takes more than a slight improvement to displace software that's widely used, but I'm sure there are things that we use that could be an order of magnitude better (according to some metric). Gmail was able to win converts because it was an order of magnitude better than the competition.

I'm a big fan of Suckless software, check out Sandy too: http://tools.suckless.org/sandy

Why do you use Sandy? I use dwm and I'm also a big fan of suckless, but I've never heard of Sandy before, and I'm genuinely curious why this would be preferable over vi or emacs (depending on which camp you're in).

Because vi and emacs are just too complex and do things that should be done by separate programs, like formatting?

Exactly: I tried learning both Emacs and Vi/Vim and it's just too complex, I have better things to do at the moment: I just want a simple text editor that works in CLI.

Joe is a similar text editor.

vim, too complex? you could say that about practically any CLI interface but it's merely a relatively steep learning curve, not a case of too much complexity. In fact vim is pretty concise and compact in terms of design

vim comes with a built-in program language vimscript and its very own spellchecker. If vim is not complex, than what is?

I could argue that nvi may be not too complex, but vim is certainly too complex.

(An good example of an editor that is not too complex but works well with external tools is Acme.)

In what sense do you dislike complexity? Is it "this software has too many features," or "this software has too many lines of code," or "the code isn't well-organized", or all the above, or something else? Don't take this as an argument; I'm likely to be highly sympathetic to whatever you say.

I tend to dislike complexity in terms of user interface, and for the most part, "out of sight is out of mind." That's why I have to use dwm over a more typical desktop environment. So I don't really mind a command line program that has a lot of options I don't use. Same thing for vim: I can easily just ignore the features I don't use (the vast majority), because of the way vim is designed.

All the above; but they are closely related.

If the program has too many lines of code, it tends to be not too well organised (because it usually means it does too much) and it usually means it has too much features (thay could be easily moved into separate programs).

    > I can easily just ignore the features
    > I don't use (the vast majority)

Please excuse my blasphemous comparison, but how this is different from how people use MS Word? :)

Oh, don't misunderstand me. Vim is complex alright, and like I say, it has a pretty steep learning curve, but it has just the right amount of complexity for it's purpose (in this case, quite a lot). Hence, an example of good design in my book.

This is an awesome terminal, and I think I'll just switch to it from urxvt.

Don't be deceived by its light-weightedness. It has very sensible features, it seems. Including full xft (anti-aliased fonts) and unicode support, and shortcuts to: zoom in, zoom out, and paste from clipboard. Typically, only very heavy-weight terminals (like gnome-terminal) would support these things.

I'm charmed. Great stuff.

Just to give you an impression of how small it is,

xterm 64K LOC rxvt 32K LOC st 3K LOC

(these numbers ain't precise)

Amazing and I am also a fan of suckless.org. I am using dwm, dmenu, sic and st now. The binary size of st, rxvt and xterm are 184k, 2.7M and 640k (on x86_64 arch, not accurate). What's wrong with rxvt's binary size? st's binary size is not so small compared to its LOC.

Perhaps your rxvt is statically linked? Mine is 104K (Ubuntu 12.04, x86_64) vs. 424K for xterm.

* Not including the Haskell runtime.

The suckless community are die hard fans of the good old UNIX and C. They only release projects written in C and RC(a bourne shell clone ported from plan9).

Haskell?

I doubt the Suckless guys are using Haskell. http://git.suckless.org/st/tree/st.c

> * Not including the Haskell runtime.

Where did you get the impression Haskell was involved in any way here?

Does it support transparency/tint for background?

(Yes, I know, but it's not '97 and I would actually like to have the thing I'm constantly looking at a bit more visually appealing.)

It's not just aesthetics. I often work on a cramped screen and being able to see just-so-slightly through the terminal is a big help.

Why not run `xcompmgr` and set the transparency with `transset-df`?

http://lists.suckless.org/dev/1009/6046.html

Don't let uriel read your request, though ;)

I imagine that would be unlikely. http://news.ycombinator.com/item?id=4654125

Oh. Crap, that's a shame, I had no idea. Thanks.

If you resize the window, does outputted text scroll (like OSX's terminal) or does it stay where it was (like xterm)? This is a feature I've been after for a while on Linux but have been unable to find a terminal that supports it.

I just built and tested it on Mountain Lion. The text stays put and leaves the newly created space empty, just like xterm. I think the point st is that it is small enough to be hackable , so it might not be too difficult to add the feature.

On a separate note; I'm not sure why, but xterm actually launches faster than st, although both are so fast it doesn't matter.

Unicode rxvt reflows text too. Only other terminal that does outside of the osx terminals.

Screen used in xterm (or any other terminal emulator that normally does not reflow) will reflow (though tmux never will).

gnome-terminal does it and probably the others based on the VTE widget also do.

Not from my experience. Last tried in Ubuntu 10.10 and it didn't, unsure of the exact version. Will double-check though as I may be wrong. I use the XFCE terminal (also VTE based I believe) and that doesn't do it.

That doesn't work for me on Fedora 17 or Ubuntu 12.04

Try surf from suckless for single-page, distraction free browsing. That and practically any other of the suckless tools; the standard of both design and execution with suckless is just out of this world, and when they say in their mission statement that they intend to comply with the unix philosophy they really do hold up to it with their code.

As an ardent DWM/dmenu user, I'm ashamed I didn't know about this earlier.

To fellow ArchLinux users, it's worth noting the AUR package is broken. I have uploaded a working PKGBUILD here: https://gist.github.com/4417214

Reply on news.ycombinator.com