I like the principles behind its design, but not supporting scrollback and saying "that functionality should be provided by tmux or something similar" is baffling when it's done in the name of removing bloat and complexity.
Not everybody wishes to use a terminal multiplexer in all cases, either.
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 very well structured and compilation only takes fraction of a second. Better yet, you're not constrained by opinions of previous commiters on what should be configurable and what - not. Which is the whole point, actually.
> Also, one should keep in mind that having to apply personal patches is perfectly acceptable for suckless software.
I don't get it. This patch increases the code base by merely 60 lines of code (104 insertions, 44 deletions).
Is 60 lines already considered bloat, in a verbose language like C?
Also, is this meant to lead to fewer complexity? Maintaining the patch separately from the code base is nothing but cumbersome. Essentially this is a long-time feature branch, which is a well-known anti-pattern regarding software quality and maintenance. What if there are more and more of such patches? What if they overlap and can't be applied together? In a central code base these formal conflicts would be resolved once and for everyone, early on.
I would have expected this feature (and its code) to be enabled/disabled by a single #define in config.h. That would be more consistent with the suckless philosophy of configuration. Or, reducing that bloat by simply enabling it always.
>Is 60 lines already considered bloat, in a verbose language like C?
It's more about features. tmux and screen are widely used, so a lot of people won't need that functionality to be duplicated. Keeping extra features separate lets the users pick and choose what they want.
It's also worth noting that suckless's software is not meant for someone who wants a turnkey solution. It's meant to be customized by most every user.
> Is 60 lines already considered bloat, in a verbose language like C?
Due to high code quality, removing even 10 lines is an achievement for suckless.org projects. Try it yourself and submit a patch to mailing list if you succeed.
> Also, is this meant to lead to fewer complexity? Maintaining the patch separately from the code base is nothing but cumbersome.
Maintaining feature as a patch prevents you from weaving it deep inside the code, adding hooks here and there just to make it work. It is harder to do, but it is the right way to make sure all feature related logic is kept in one place.
I have some pet suckless inspired projects. During development I introduced some useless features such as pthread support just because I learned about them. Then once I realized they are useless I removed them. It greatly improved code structure.
> Maintaining feature as a patch prevents you from weaving it deep inside the code, adding hooks here and there just to make it work. It is harder to do, but it is the right way to make sure all feature related logic is kept in one place.
I'm used to achieve this by keeping each topic in a separate module (in C: function or file, in other languages: module, class, whatever). You'd then have clear entry points into that module.
Interestingly, the given patch isn't structured like that. So I'd argue that code would benefit from becoming a first-class citizen in the code base. As a patch it just gives the illusion of a well-separated feature. (Because a patch file is always a single file, no matter how much the changes are scattered around in the code base.)
> I have some pet suckless inspired projects. During development I introduced some useless features such as pthread support just because I learned about them. Then once I realized they are useless I removed them. It greatly improved code structure.
I fully agree that removing useless features does not only shorten, but simplify code. However, given that by far not everybody uses screen/tmux, I disagree with the "scrolling is useless" assumption here.
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.
What lisaberlin wrote applies - suckless is like Unix: user friendly, just very selective about who it decides to make friends with.
But in this case, I would disagree. The file is quite readable (way more than most text config files I've seen), and the single command to compile is even included in the README. If you're the kind of person that purposefully downloads a new terminal, rather than using the built-in one, you can probably configure st just fine.
Seems like kind of a pretentious choice... they've structured their program so the config file is a .h file just so you can feel cool when you compile it to change font size?
Not having the skills isn't the thing that should stop someone in either scenario, it's not wanting the skills. Arch is great for a beginner that wants to know how to set up their own bootloader and similar things, you can use Ubuntu for years without gaining that knowledge. Or how much C editing and compiling does the average Unix user happen to run into?
There's very little natural progression in computer use, people do things the way they know how until they decide to learn more. Think of how many time's you've seen some family member slowly select file-save without ever figuring out ctrl-s.
Exactly. I would never use it, but I'm perfectly alright having something targeting a niche perfectly. It's better than trying to please everybody and ending up being "meh".
Agreed in general. (As a small counterpoint: I helped a beginner get familiar with Linux. We tried Ubuntu first, and she hated it. She switched to Arch and has been happy ever since.)
The Xmonad window manager is configured by editing its source code as well, and believe me, you don't have to know Haskell to do it. They pushed the DSL approach to a point where the main function reads like a configuration file, whose format can be learned just by looking at it.
this is not entirely true, xmonad's config file happens to be a haskell file, but I don't need to recompile the whole xmonad project if I want to change it, I just start xmonad again.
It does some tricks to do this (mainly the _main_ xmonad executable compiles a custom binary for you taking the xmonad.hs as input), but it's a different case.
If this experience has been improved, I might try xmonad again. I used it for 2.5 years but switched to i3 in 2013 after finding myself in cabal hell for the umpteenth time. Recompiling GHC to make my window manager work was not my idea of a good time.
I switched from xmonad to another window manager and eventually to i3 many years ago, and there's no way I'm going back.
Yes, you can do simple stuff in xmonad without knowing Haskell. But for more complicated stuff, you have to either copy and paste code that you don't understand, or ask someone who knows Haskell to write it for you. And there's no way you're going to be able to do troubleshoot non-obvious problems without either knowing Haskell or once again asking someone who knows Haskell to do it for you. That's way too much of a pain in the ass.
Configuring and troubleshooting i3 doesn't require knowing Haskell, is really simple, flexible enough for what I need, and any advanced functionality I want it to perform I can program in my own language of choice.
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.
These reasons are valid, but I'm more interested in technical reasons.
I switched to tmux when I needed to launch a lot of simultaneous jobs, categorized in three sessions (starting in "active", moving to "success" or "fail" when finished). I couldn't achieve it in screen at the time. The CLI interface of tmux is not very intuitive and I think somewhat inconsistent (maybe a bit like git?), but at least
I could achieve what I wanted without major compromises.
After a quick google search my impression is that running a shell command in a particular GNU screen window is still painful.
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.
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.
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.
Different people want different features. There's no way they're going to remain minimal and please everyone.
They have to choose the feature set, and if other programs can provide a feature that some users want, that seems like a feature ripe for pruning. I think they made the right choice.
I always find tmux's scrollback to be vastly inferior to a native terminal's though.
There are several reasons, but the biggest is that I'm pretty sure it's not possible to get more than a screenfull of text to my local X11 PRIMARY selection.
You can always use ssh and something like xclip or pbcopy.
Also, I always use mosh for ssh (when possible) so that I can recover my connection if I run into network issues. Since mosh works by synchronizing a virtual screen, I don't get scrollback at all without tmux or the like.
Keep in mind that your terminfo has to support this, so make sure your ncurses-term package is the latest release from Jan 28.
I also made a patch for st to support OSC 52 propagation into Xorg, but it was rejected by the st maintainers because it uses base64 (as the OSC de-facto spec from xterm dictates).
The patch for st is however in a branch of the Wayland-fork of st
Unfortunately many ssh servers gratuitously disallow X11 forwarding; tcp forwarding can accomplish the same, but then setting up DISPLAY &ct. need to be done manually.
In the latest git builds of tmux (with the latest terminfo db from ncurses), you can have clipboards propagate from remote tmux to local tmux (nested configuration) using the new OSC52 control sequence implemented in a patch from 2 weeks ago.
Also, if your terminal emulator (rxvt, xterm on Linux and mintty on Windows) support OSC52 escape sequences for clipboard setting, this means you don't need X11 forwarding anymore, since you can set your X11 clipboard from tmux.
If anyone can help me get in touch with the libvte people, I want to patch OSC 52 support in there as well, since this is a great feature that should _not_ be relying on X11 forwarding or whatever.
I know that there is an option for integrating tmux's internal clipboard with X11's but I haven't bothered with them because I prefer to keep the clipboards of the various terminal apps I use separate.
It depends ultimately on the terminal to support it though. Only Linux terminals that support it atm are xterm and (u)rxvt, and there is an out-of-tree patch for st that I made (though it was rejected for being too long (around 40 lines).
It is explained in the info that scrollback is implemented in dvtm. Duplicating the functionality would probably go against the general minimalist Suckless design philosophy.
Non-goals:
unlimited scrollback buffer (done by dvtm)
Alacritty uses the same argument against scrollback and tabs -- that these features should be handled by something like 'tmux': https://github.com/jwilm/alacritty
You can with the mouse as well. st doesn't support the OSC52 (Ms termcap) for setting the selection by this method, though I have an out-of-tree patch that does support it (also available as a branch in the Wayland port).
They use patches of the source code for plugin style functionality so it remains as minimal as they want and we can add features at will. There is one for scrollback
What's the problem with typing tmux? I think this is exactly right for the typical audience of suckless projects. No dwm or dmenu users are complaining about "missing features".
[modifier]+shift+insert or [modifier]+shift+v are the default bindings for paste. [modifier] is most commonly Alt or Super (the Windows key). Keep in mind that your window manager might already have a binding for these, preventing them from working.
This thread is like every thread on suckless software ever.
>This software, which specifically states that it caters to a niche, doesn't cater to my needs. I'm not going to consider thought that I might not be part of the niche it's catering to and complain about it instead.
As much as I love st, I had to stop using it recently. When using a bitmap font in tmux, large amounts of text sent to stdout bring my computer to a standstill. X is using 100% of a single core. I've switched to gnome-terminal and the issue is gone.
This, along with the generally accepted notion that Gnome Terminal is one of the slowest with output, puts the whole minimalism idea under a serious question. "Do one thing, but do it well", the saying goes.
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 comparisons like that, apparently using a TTF font. Hopefully the bitmap font performance problem is not due to the general design, but a regression in a special case.
Minimalism is a tempting proxy for performance, but it often isn't. rg/ag/pt aren't some of the fastest file searchers around because they're short and don't pull cool tricks.
(It's arguable that a backtracking implementation is not the simplest, although I think it is -- and even if it is, a FSA compiler clearly isn't!)
And, finally: people tell me Clojure is slow, and I tell them that it lets me write correct concurrent algorithms I understand. (See alioth shootout results.)
It could have to do with that xterm is trying to faithfully emulate an actual terminal (viz., VT220 with extensions) by replicating the VT's internal state machine, whereas libvte is trying to approximate the behavior of xterm and cutting corners as it does so.
Note that while libvte seems to have greater throughput, its latency is terrible compared to 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.
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.
Even though I can't stand to use their software (or their aesthetic, or their ethos...) I'm very grateful that suckless exists. The source serves as an excellent reference if you want to learn, say, how a (non-trivial) window manager works, or how IRC is implemented in practice, or how to wrap the WebKit/GTK+ interface. The code is usually quite straightforward, and the lack of features/config makes it fast and easy to see what's going on.
I think the suckless project has correctly identified that a lot of software sucks, but their attempts to make it "suck less" are focusing on the wrong points. A lot of mainstream software is grossly inefficient, bloated and resource-intensive, and that's not necessarily because they're featureful. It's certainly possible to write software that is both featureful and efficient, but suckless aggressively cuts features instead of optimising, to reduce the perception of inefficiency; what's left is not necessarily efficient.
In fact, I don't remember the details now but I recall looking at the source for another one of the suckless applications and finding some pretty inefficient algorithms. I think the other comment here about st being CPU-intensive with high output rates is an example of this.
Ironically, one of the reasons I think mainstream software sucks is because newer versions also tend to remove configurability and features often for the same goal of reducing bloat.
For better or worse, Suckless's problem isn't with code bloat so much as code complexity. More features mean more code to debug. Better algorithms can also mean more code to debug. If you constrain your design scope, you can write vastly simpler programs that are more stable and easier to comprehend.
It's the same rationale that leads one to use a pen and paper rather than a note taking app.
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 stuff isn't targeted toward the average user, just this small niche. Their browser, surf, doesn't even support tabs as far as I can remember.
I've never used surf, but I really do like tabbed. It plays super nicely with most tiling window managers I've used, and lets me get the single best feature (ymmv) of i3 on xmonad.
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.
You're clearly not their target audience if those are your takeaways. But there are lots of people out there who do prefer to recompile instead of configure and find suckless feature sets to be inline with their own requirements. To say that a product "sucks" because they don't cater specifically to your arbitrary desires is grossly unfair.
First of all it is "suck less" not "suckless". ie "less bloat/features" rather than "hey look at our perfect software". This is a point reiterated on their site repeatedly (including the <title> tag on their home page: http://suckless.org/)
Secondly, it's all very tongue in cheek. After all it's aimed at the OpenBSD crowd and like minded people. It's not really meant to be taken literally by the general computing audience - not even within the wider FOSS community.
Lastly it's sad day for HN when negative comments get up-voted and positive comments defending niche software get down-voted. What happened to respecting our peers and acknowledging the massively wide range of personal preferences and usage habits?
> What happened to respecting our peers and acknowledging the massively wide range of personal preferences and usage habits?
I absolutely wasn't trying to be disparaging of them. I understand that there are people who love their work, and I love some of their software (dmenu).
My point was more toward the parent I was replying to - i.e., that the message from the suck-less crowd that other pieces of software "suck" is just an opinion. In the same way that they think (for example) the KDE desktop sucks, it's allowed to think that their products suck.
But I suppose that it can be seen as disrespectful, and I understand that. There is definitely room for airing one's opinion in a less inflammatory way.
> To say that a product "sucks" because they don't cater specifically to your arbitrary desires is grossly unfair.
Then again, if they name their project(s) "suck less", it's completely fair to say it sucks. If they can have arbitrary standards about what constitutes suckage, why not us?
The code does unsafe things in signal handlers (vfprintf, for example), and hides some things in macros that I wouldn't expect to see hidden (like the assignment of the global "argv0" variable, defined in st.c, is assigned in a macro from arg.h).
Yes it's strange, it's one of the reason I stopped using C++ as a matter of fact. Given the innate amount of code required in C++ constructor to initialize objects, you'd think that would be very handy.
BTW, shameless plug, but my own simavr uses these C99 features as more or less the whole basic structure on how multiple cores are described, see a sample core declaration [0] for example. The beauty is that there is no code involved in the declaration, it'll be 'const' too. Imagine the boilerplate you'd need to do that in C++!
I used st for a good year and it worked really well! I've switched recently for features like the ability to change the font size without recompiling, etc. Despite its spartan feature set, st is quite usable.
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.
Plug: I maintain a fork of termite which doesn't require Daniel's patched VTE3 fork; and guts most of the exotic vimmy features.
I really like VTE's behaviour; even if the performance is a bit worse than XTerm (though worlds ahead of what I've seen on OSX with iTerm2 and Terminal.app). I rely on using iBus input methods in the terminal on a daily basis, and VTE handles this wonderfully.
I've also gutted a lot of stuff from termite in my own fork (overaly, vi mode, clickable urls) and it definitely makes for a lovely minimalistic terminal. I'm thankful for termite being so simple (granted the lifting is done by a lib) that this is possible without much effort.
I just wish I could log the scrollback buffer so that I could open an actual editor on it, but I don't think libvte exposes anything to do this.
Hey, thanks for the tip on Termite. I've been using it since reading your comment and it's awesome. Cut and paste and URL opening both work flawlessly!
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.
Try spartan way for vim too. Used to have huge list of plugins and exotic vim hacks in my `.vimrc`, nowadays ain't even using plugin manager. `:colorscheme blue` and off you go.
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 ANSI control code compliance with "works in xterm".
The problem with this situation, as mentioned on the st page, is that xterm is unmaintained and unmaintainable.
st is trying to be a maintainable replacement, making improvements like vector fonts, and not being shy about ignoring legacy/niche/solved-elsewhere features.
- 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.
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.
Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags.
What's more, many developers (myself included) aren't afraid of jumping into someone elses code and modifying it to behave how we want.
Let's also remember that a great deal of software you don't even think about also runs this way; they'll have config flags to add and remove features at compile time (run Gentoo or FreeBSD ports for a few weeks and you'll see what I mean).
So having hardcoded options isnt that ridiculous nor uncommon on Linux. However mainstream desktop distros do a good job at hiding that from their users by picking sane defaults for them.
> Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags.
Cool... Now I know that it's not just me that does this then. :)
> Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags.
Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs.
> Do you not build stuff that needs to run differently on production systems than development systems? Simple things like credentials or connection URLs.
If you're building an MVP then the first and foremost concern is getting a proof of concept product running. However to answer your question I don't really see how editing list of constants in an AOT compiled language is any worse than having to do the same in any of the hundreds of popular web solutions written in languages like PHP where they often embed config as source code variables. It's the same issues with hard coded settings in source code but the difference is how your continuous integration pipeline / code deployment scripts are configured. So it's quite an easy problem to solve once you look at the deployment automation.
Obviously the end goal would be to have readable configuration files for different environments. But pragmatically real world code often ends up being rushed and hacked to meet deadlines rather than nurtured, following industry best practices at every point throughout it's development cycle (assuming your company even has a documented development cycle. Many don't!)
Counter-example: Xmonad. Here's how I "configure" it:
Open ~/.xmonad/xmonad.hs. It's Haskell code, but frankly it reads like a configuration file, with a big list of shortcuts.
Edit the "code". You don't need to know Haskell, just follow the syntactic conventions you see there. Worst case, you have to search for configuration tips on the web.
Save xmonad.hs, hit the "recompile Xmonad" shortcut. You've now recompiled and restarted Xmonad, and all your windows are still where they were before. Application state survives recompilation.
Finding the right settings is a relatively slow process. Also, finding the right values for 80% of the settings is fast, but fiddling with the rest can take time. Trying something new also becomes harder.
For the vast majority of user-facing programs, run-time configuration is a must. A fancy GUI for it might be superfluous; a simple text file / command-line way to set options should always be available.
This sort of rules out binary distributions, or changing settings on a remote machine where you don't have the build dependencies installed. The latter may be irrelevant for a terminal emulator, but not for the general case.
In my experience if one can edit config files on a system, one has room to install a minimal C compiler. And one can distribute things in a binary form even if the config requires compilation. Consider distributing an application as a library or object files when the target machine needs to compile and link only the config file.
The difference between a config file that's dynamically loaded and a file that is compiled in is surprisingly small, as long as the compile times are very fast. First noticed that when using XMonad: one shortcut to recompile it and reload it, that's just as fast as editing configuration of any other window manager.
If it's one thing I've often had to change across systems (hardware and operating systems) it's things like font type and size. If one works mostly from one workstation (eg: a laptop) this is less of a hassle (just need to change on each new generation of ppi, and perhaps on some major system upgrades) -- but then one might want to switch things up as new fonts are released every so often.
Edit-compile-run is a rather complicated way to tune font size compared to a slider.
And on that note, while I admire ST for its simplicity, I've been a happy user of Sakura for the past few years (though, sadly not on windows 10... I've yet to find a really good console for w10).
For windows ten I'm using a combination of babun/WSL and cmder. But I agree that there is no good terminal emulator. It's not terribly surprising though. When those aren't enough I have a "seamless" ubuntu VM running.
I think it's somewhat surprising that they got the Linux subsystem for Linux working well, but apparently didn't spend much time on making a proper terminal experience.
Don't get me wrong powershell/the standard terminal is miles ahead of the old crappy cmd.com - but bundling a solid terminal would've gone a long way to pacify my desire to dual boot Linux (read:stop using w10) on my Surface pro.
If I weren't teaching students that run w10 on their own pcs, I would probably have relegated w10 to a vm/wine under Linux.
I use st in i3 under Cygwin on Windows 8.1. If Cygwin works in Windows 10, that (or any other Linux terminal manager of your choice) should be doable there too.
Well, the promise of the Linux subsystem is kind of to not having to run half-ports like cygwin in the first place... Still, appreciate the tip. Any idea how well that works on a high-resolution display like the surface 4?
Does not apply to all software. It is just a terminal (and pretty fast terminal). I don't need change options for ST often. Changed probably few times just after upgrade to new version.
More often options are changed on the shell (ZSH in my case)
Then even more often on tmux.
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.
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.
(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 love Terminology, and the entire 90s vibe of EFL and Enlightenment generally. So unashamedly not flat design in a world of Jony Ive / Google Material Design conformity.
It's honestly not the most important limitation of Terminology (except maybe to you). It doesn't support re-ordering or renaming tabs. It doesn't support searching into scrollback. It doesn't fetch terminfo data.
It's still the best terminal emulator out there. Incredibly fast in software-only, even better when hardware accelerated, skinnable and configurable.
This is my favourite terminal. I have it configured to run tmux, and couldn't be happier. Lightning-fast, stable as can be, it gets out of my way and lets me work.
I've been using it as my main terminal for I think over 2 years, selected my patches, tweaked it a little. Great hackable little thing with comprehensible code.
xterm's support for the Tek graphics terminal is actually quite neat, since you can use it with for example gnuplot to plot things over a (bad) SSH connection.
Also there is still some niche software that still requires it (for example IRAF which sadly is still going strong in the astronomy community).
Indeed it is and not just for that. When I developed the firmware for our my company's laser product I exhaustively used the Tek graphics support for debugging purposes. Kind of neat if you've got only a serial connection and have to plot graphs. Much better than dumping it into a file and plotting it with gnuplot.
Interesting. I've been wanting a better terminal for some time. rxvt is super buggy, especially with clickable URLs. xfce4-terminal is better but select-to-copy is flaky and doesn't always copy the text I select.
I really wanted st to work for me but something is wrong with the character sizing when using Source Code Pro (17pt) as the font. I installed this on my Arch laptop (a hidpi ThinkPad T460s) and something is seriously screwy with the fonts. At top is xfce4-termina; on the bottom is st:
The two terminals in your screenshots are using different fonts.
Notice the dotted zero in the top terminal (xfce4-terminal) and no dotted zero in the bottom terminal (st).
I suspect st is not recognizing the font name you're giving it, and to fix it you have to play around with different ways to telling st the name of your font. What worked for me for the Inconsolata font was "st -f Inconsolata" or "st -f Inconsolata:size=11".
st does this when you don't give it the right font path and config. There is one compiled in, and that's what it's using if you aren't passing a font when you start it. Right now, whatever font it's trying to use doesn't exist, and your screenshot is a typical result of that.
Try looking for the actual font name with "fc-list | grep -i source", maybe it is not what you're expecting.
A few months ago I was having trouble with getting some TTF BIOS fonts recognized by urxvt and fc-list made me realize that I should've escaped a couple dashes in the font name.
> I would report this to the author but I don't see any way to do so.
Godspeed, I moved away from all suckless software because the developers are all massive jerks. They'll ignore your bug reports unless you spend an unreasonable amount of time doing intricate debugging, and if you refuse they'll be sure to remember your name and act hostile if you ever go back into their IRC. That's been my experience with Surf and something else (I don't remember what, but it wasn't st) anyways.
I find terminal emulators on Linux to be woefully inadequate after getting used to iTerm2 on OS X. Can anyone recommend a Linux terminal emulator that even comes close in terms of features and performance?
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.
There's nothing wrong with features that give you access to the wider operating system. Like it or not, the modern operating system is more than just terminals and CLI tools, and there's no reason to be condescending to those who don't live exclusively in the terminal.
A large part of what makes iTerm2 popular is how well it works in tandem with MacOS. Things like cmd+click to open (useful because you can use it on data that was spat out from a previous command invocation), paste filtering, and the fantastic built-in multiplexer/tabbing system.
That said, most of what makes MacOS users like iTerm2 just wouldn't be as useful on any other operating system, because its so tightly coupled to the wider OS.
Autocompletion is on <⌘-;> (spell check) instead of <Esc>, and it works strangely: "$ ls trunk/<cmd-;>" suggests other directories around trunk (like tags and branches), when it should list trunk's contents. Cmd-click on path cannot go to partial path. It also cannot "open in app", only in default app (^cmd-click doesn't help). I always can select or triple-click and "$ open [-a ...] <cmd-v><cr>" to do that; or stop being fool and just type "open ." and do whatever I need right in Finder. Colored tab's colors blend to barely visible when deactivated. Changing color themes in settings does nothing at all.
I'm not arguing that features aren't needed. I'm arguing the hyping of little-to-no working "features" that it tries to sell in place of REAL tools and .files that were there for decades.
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 your file browser, or whatever.
Quadruple-click smart selection should be doable with urxt's perl extension feature.
Selecting within a tmux pane: you got me on that one. I'm not aware of a terminal that does that, but again, it should be possible to do with urxvt's perl extension feature.
Regarding the "safer command line paste", Linux can do the same with bracketed paste mode.[1]
For splitting panes, I just use tmux, vim, or emacs.
Performance? I can't think of a terminal emulator which performs worse than iTerm2 on any platform; other than maybe Cool Retro Term, but I don't think performance was much of a consideration there in the first place.
If you're looking for native tmux tabs, Terminator unstable has initial support, for instance.
If you're looking for things like toolbelt, or built-in regexp highlighting, or other (arguably nice) bells and whistles, I suspect most of them would be provided by separate utilities. (Yes, it's a distant echo of the "Unix way".)
Bookmarks in scrollback are neat, though, and cannot be easily added by a third party. I don't remember an implementation, though.
I'm working on a new terminal which takes a few cues from iTerm2 and also adds other unique features. It is not up to production level quality like iTerm2 but you are more than welcome to try it out.
I wish apps would stop implementing their own fullscreen functionality/hotkeys/etc, and we could all start relying on window managers (or DE's) to provide this.
On-topic, I really like that if I super+F firefox, it actually behaves full-screenish and hides the its bars. I wish most apps would do this.
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.
It really is fantastic to see a new _improvement_ on something like a terminal in 2017, that isn't written in Javascript / Coffeescript / Some other web technology that deploys 100+MB of libraries.
And it depends on how you define "improvement" since this lacks features many would want. And I'm talking about features in native apps, not web-tech apps.
Not everybody wishes to use a terminal multiplexer in all cases, either.