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.
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.
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).
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.
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
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.
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.
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.
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).
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.
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.
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.
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.