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.
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.
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.
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.
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.
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.
Both custom patches and config.h changes can be saved in the package manager, which will then apply them automatically to new versions.
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.
I like to use the term "super-user friendly", as a compliment.
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.
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.
http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Doc-Conf...
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.
It absolutely seems like very conflicting decisions user-experience wise.
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?
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.
Sure. And let's go full circle while we're at it: GNU screen supports connecting directly to a serial device :)
Last I checked tmux doesn't.
[1] https://www.gnu.org/software/screen/manual/html_node/Window-...
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.
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.
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.
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
https://github.com/michaelforney/st/tree/selection
Another option if you use nested copies of tmux is to use this feature to get the remote clipboard into the local one, then yank with xclip.
[Edit] Assuming you have SSH configured to forward to your local X server [0].
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.
Non-goals:
unlimited scrollback buffer (done by dvtm)
Not everybody wishes to use a terminal multiplexer in all cases, either.