6 ms·

This. 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 chan

by aexaey 10y ago

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

nightcracker 10y ago
It is still bizarre because not every user wants to and/or doesn't have the skills to do that.
- lisaberlin 10y ago
  Yes, and that's perfectly ok. These people simply aren't the target audience, just like you wouldn't recommend Arch to a Linux beginner.
  - sametmax 10y ago
    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".
  - boomboomsubban 10y ago
    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.
    - Ziomislaw 10y ago
      if you don't like it than fork it
      - boomboomsubban 10y ago
        I find in hard to fork human behavior and have anything one might consider a good adoption rate.
  - eru 10y ago
    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.)
- icebraining 10y ago
  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.
  - woah 10y ago
    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?
    - wtetzner 10y ago
      I suspect it's not so you feel cool, but because it means the program doesn't need a parser for config files, and because it's more flexible.
      - contras1970 10y ago
        parserless configuration is easily achieved with stuff like envdir: https://cr.yp.to/daemontools/envdir.html https://cr.yp.to/daemontools/envdir.html
        juliangoldsmith 10y ago
        That just parses environment variables, instead of files.
        wtetzner 10y ago
        Not to mention that it's yet another dependency, which is another thing that's avoided by doing configuration through a header file.
  - 10y ago
- loup-vaillant 10y ago
  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.
  - dedsm 10y ago
    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. http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Doc-Configuring.html http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Doc-Conf...
    - sevensor 10y ago
      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.
      - pmoriarty 10y ago
        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.
- deleted 10y ago
  [deleted]
hobarrera 10y ago
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.
- dhimes 10y ago
  Also, I like different colors for different things. Production server terminals look different that staging server terminals that look different than development terminals.
  - aexaey 10y ago
    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. [1] https://github.com/chriskempson/base16-shell https://github.com/chriskempson/base16-shell
- bratch 10y ago
  Gentoo's package manager (Portage) deals with this quite nicely for packages like st [1]. Both custom patches and config.h changes can be saved in the package manager, which will then apply them automatically to new versions. [1] https://packages.gentoo.org/packages/x11-terms/st https://packages.gentoo.org/packages/x11-terms/st
vog 10y ago
> 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.
- juliangoldsmith 10y ago
  >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.
- ycmbntrthrwaway 10y ago
  > 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.
floatboth 10y ago
> to change font, colour scheme, or hotkeys/shortcuts 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 https://github.com/chriskempson/base16-shell and the font is passed via the -f flag.

by aexaey 10y ago

nightcracker 10y ago

It is still bizarre because not every user wants to and/or doesn't have the skills to do that.

lisaberlin 10y ago
Yes, and that's perfectly ok. These people simply aren't the target audience, just like you wouldn't recommend Arch to a Linux beginner.
- sametmax 10y ago
  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".
- boomboomsubban 10y ago
  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.
  - Ziomislaw 10y ago
    if you don't like it than fork it
    - boomboomsubban 10y ago
      I find in hard to fork human behavior and have anything one might consider a good adoption rate.
- eru 10y ago
  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.)
icebraining 10y ago
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.
- woah 10y ago
  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?
  - wtetzner 10y ago
    I suspect it's not so you feel cool, but because it means the program doesn't need a parser for config files, and because it's more flexible.
    - contras1970 10y ago
      parserless configuration is easily achieved with stuff like envdir: https://cr.yp.to/daemontools/envdir.html https://cr.yp.to/daemontools/envdir.html
      - juliangoldsmith 10y ago
        That just parses environment variables, instead of files.
        wtetzner 10y ago
        Not to mention that it's yet another dependency, which is another thing that's avoided by doing configuration through a header file.
- 10y ago
loup-vaillant 10y ago
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.
- dedsm 10y ago
  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. http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Doc-Configuring.html http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Doc-Conf...
  - sevensor 10y ago
    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.
    - pmoriarty 10y ago
      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.
deleted 10y ago
[deleted]

hobarrera 10y ago

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.

dhimes 10y ago
Also, I like different colors for different things. Production server terminals look different that staging server terminals that look different than development terminals.
- aexaey 10y ago
  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. [1] https://github.com/chriskempson/base16-shell https://github.com/chriskempson/base16-shell
bratch 10y ago
Gentoo's package manager (Portage) deals with this quite nicely for packages like st [1]. Both custom patches and config.h changes can be saved in the package manager, which will then apply them automatically to new versions. [1] https://packages.gentoo.org/packages/x11-terms/st https://packages.gentoo.org/packages/x11-terms/st

vog 10y ago

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

juliangoldsmith 10y ago
>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.
ycmbntrthrwaway 10y ago
> 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.

floatboth 10y ago

> to change font, colour scheme, or hotkeys/shortcuts 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 https://github.com/chriskempson/base16-shell and the font is passed via the -f flag.