9 ms·

St – simple terminal

92 points by cleverjake 12y ago

Xylemon 12y ago
Seems nice, however I do like the idea of a GTK2 based and tabbed terminal. Sadly, a lot of them feel very bloated.
- exDM69 12y ago
  st uses the Xembed protocol so you can use tabs with it using the "tabbed" utility from the same site (ie. you can embed many st instances into tabbed). Or just use tmux for "tabs", you'll need something like that anyway for scrollback, etc.
- anoother 12y ago
  evilvte
antirez 12y ago
Every software is a product, even if it is OSS and no money exchange is involved at all. There is a designer, and a final user. The idea of this product is that terminals don't need to scroll up into the past history, actually doing this well is one of the most critical aspects of a terminal as a good product for end users: retain history, do it reasonably when programs controlling the cursors are executed, don't get super slow if there is a lot of history already in memory, and so forth.
- chriswarbo 12y ago
  > actually [scrolling up] well is one of the most critical aspects of a terminal as a good product for end users You've clearly misunderstood the point st is trying to make. Not only is it not critical, it's a bad idea for a terminal to store and scroll history! Yes it's nice to have a history to scroll through, but other programs (screen, tmux, Emacs, etc.) are much better at doing that than terminal emulators are! For many people, like sysadmins, it's crucial that shells can be accessed over a network. Does that mean terminal emulators should build networking into their code? No, since SSH already does an excellent job. For many disabled people, it's crucial that shells can be speech-driven. Does that mean terminal emulators should build speech recognition into their code? No, since external systems (Sphinx, etc.) are already tackling this problem. Of course, from an "end user" perspective it would be nice to have "one application" which does all this. The beauty of the UNIX philosphy is that we can write such an application easily (untested, but you get the idea): #!/bin/sh if zenity --entry \ --title="New Terminal" \ --text="Enter the shell URL (blank for local shell)" \ then st -e "tmux -c ssh '$?'" else st -e "tmux" fi
  - antirez 12y ago
    That's why I addressed it in the POV of a product. It's basically subjective. IMHO the "terminal product" should have history handling included.
    - chriswarbo 12y ago
      If you're thinking about a "terminal product" then why single out st's lack of history at all? That would be like claiming Excel lacks presentation capabilities. Whilst it's a true statement, presentation facilities are irrelevant to a spreadsheet; they're available in the PowerPoint component of the Microsoft Office suite, and they're designed to work together, so it's a complete non-issue.
- fake-name 12y ago
  You're entirely missing the point. Scrolling is already broken if you use any terminal multiplexer (such as `screen` or `tmux`). As such, having an additional, useless layer of scrollback on the client is both confusing and pointless, so they removed it.
stormbrew 12y ago
> Some random program complains that st is unknown/not recognised/unsupported/whatever! I really wish there was a better way to deal with this (I have the same problem with rxvt-unicode-256color). I'm obviously not going to make install a graphical terminal emulator on some random server I'm logging into.
- vortico 12y ago
  Put the following in your shell configuration. alias ssh='env TERM=xterm-256color ssh'
- hoeppnertill 12y ago
  tic -s st.info or setting your TERM variable should help.
  - stormbrew 12y ago
    I meant the distribution problem of getting the file to the server. I grant that it's a petty annoyance, but it is still an annoying thing. And logging into a new server always carries with it the question of whether it's worth fixing it permanently when you barely use it. For the machines I regularly use I have terminfo files in my dotfiles git repo.
- Sanddancer 12y ago
  I'd argue that they should go the route that most terminal programs do and just announce they're xterm, or at least have a config file option for doing so.
AceJohnny2 12y ago
I like suckless. I use some of their tools within my Awesome(WM) sessions. However, I don't see the point of St. There are dozens of other graphical terminal emulators that were created with the exact same goal: "Xterm's codebase sucks, we can do better". FWIW, I've (currently[1]) settled on ROXTerm, which (on Debian and Ubuntu) comes in GTK2 and GTK3 variants. I use Tmux within it. It does FreeType and FontConfig fonts well, which I care strongly about. Its colour scheme is configurable and it's not tied to a desktop environment. It does use libvte from Gnome to implement the terminal emulator widget, and I'm OK with that. Less NIH please! [1] After using Gnome-Terminal, Konsole, and RXVT-Unicode for a while. I doubt my quest has yet ended.
- e12e 12y ago
  I've been using a few - in the end I landed on sakura: http://www.pleyades.net/david/projects/sakura http://www.pleyades.net/david/projects/sakura I don't quite remember why I ended up moving from urxvt to sakura (and not eg: roxterm) -- but I think it was a combination of it being light (enough), easy to set up without any kind of window decorations, as well as a sane way to pick and choose fonts. With the current gtk ~/.conf-scheme it has a nice ini-like config file, and I can easily have different font preferences on my laptop, my netbook and my desktop (all different screen sizes and different PPI). FFW I use a spartan xmonad setup, and typically run one, or a handful of terminal windows, each with their own gnu screen instance (typically one local, and a few remote screen instances over ssh. Sometimes I'll have more than one view/windows to one screen session -- and sometimes I might have a screen for a chroot or local vm/container of some sort).
  - deleted 12y ago
    [deleted]
  - emilburzo 12y ago
    Thanks for letting me know about sakura, I think it's the first one to actually match the rendering speed of xterm. I do have one question though, why are the colors more pale in sakura than in xterm? And is there any way to change it?
Zardoz84 12y ago
I use Konsole and yaquake always. Tabs, colors, profiles (I just have one for neovim), nice font rendering, split windows, copy&paste from clipboard... Apart, Windows needs a good terminal. Console2 and ConEmu, not end to work fine... I get strange issues with colors every time that I connect to ssh against a GNU/Linux machine and open vim.
- RobinBlk7 12y ago
  ConEmu works fine with colors. Your ssh client does not...
  - Zardoz84 12y ago
    Yeah, I just learned that I should use ConEmu + Putty. At least now, I don't get weird colors and a grey background filling all when I open vim. But I keep missing having something like Yakuake or Konsole.
    - p8952 12y ago
      I use Mintty, the terminal which comes with Cygwin, and it works great both on Windows and while ssh'ed into Unix boxes. Windows + Vim: https://i.imgur.com/soTIhNy.png https://i.imgur.com/soTIhNy.png SSH + Vim: https://i.imgur.com/aLs9ACy.png https://i.imgur.com/aLs9ACy.png
- shmerl 12y ago
  Konsole is great.
- davidgerard 12y ago
  If I'm stuck on Windows, I just use a Cygwin console and ssh to the world.
otikik 12y ago
> xterm is bloated and unmaintainable. [...] It has over 65K lines of code and emulates obscure and obsolete terminals you will never need. The popular alternative, rxvt has only 32K lines of code. This is just too much for something as simple as a terminal emulator; it’s yet another example of code complexity. Ok, I am interested. > How do I scroll back up? > - Using a terminal multiplexer [shows tmux example] Emm... tmux is a 32K lines of code. That kind of defeats the purpose of the opening paragraph.
- agumonkey 12y ago
  I heard dtach + dvtm were smaller, but I'm not sure.
  - chriswarbo 12y ago
    Nice, not seen dvtm before. Since I've not seen it mentioned in other multiplexer comparisons I was assuming it's not in major repos yet, but an optimistic "nix-env -i dvtm" has installed it!
    - agumonkey 12y ago
      nix really does make people optimistic
  - not_with_retard 12y ago
    You should be using abduco instead of dtach now http://www.brain-dump.org/projects/abduco http://www.brain-dump.org/projects/abduco
- klez 12y ago
  I think the point is: do one thing and do it well. In this view, I guess it's not the terminal's duty to do multiplexing, scrolling etc. Tmux is meant to do the job, so its codebase size should not be added together with st's. They're separate software, each doing its thing and doing it well, an approach completely opposite to that of other software (e.g. emacs) that do lots of things.
erikb 12y ago
suckless sounds quite like a good name. I'm currently also working on some terminal style I/O and I can totally understand why there are programs with >30k lines of code just for being a terminal emulator. terminal communication is not really standardized. It has grown since a time where "computer" meant a person who calculates things. So I'm not sure it St could arrive at a stable state without also having a few thousands lines more than it would like to have. But what is wrong with Gnome-Terminal? For me it works well enough out of the box. I literally didn't do anything beside increasing the scroll buffer and haven't run into enough troubles yet to switch.
- Argorak 12y ago
  The source directory of libtsm, which only does the state handling for an abstract screen, is already ~11k without tests, so 30k doesn't surprise me. http://www.freedesktop.org/wiki/Software/kmscon/libtsm/ http://www.freedesktop.org/wiki/Software/kmscon/libtsm/
- chriswarbo 12y ago
  > But what is wrong with Gnome-Terminal? The dependencies: https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/gnome-3/3.12/core/gnome-terminal/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/g... If you're using Gnome, you probably have those already so it's no big deal. The same goes for Konsole in KDE: https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/kde-4.14/applications/konsole.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/k... If not, pulling in a few hundred MB of dependencies for a terminal emulator seems distasteful. st is much more self-contained: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/st/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio... That's why st is usually compared to xterm; they're small, basic and desktop-agnostic.
  - erikb 12y ago
    That's good to know. Without Gnome(3) Gnome-Terminal might not be the right choice.
aartur 12y ago
> xterm is bloated and unmaintainable (...) It has over 65K lines of code and emulates obscure and obsolete terminals you will never need. The way these things are usually implemented is that there is an interface of a "terminal" and implementations. As long as implementations do not break the abstraction and do not require modifications in the interface and other parts of code these implementations do not decrease internal software quality. They only cause bloatedness in terms of size of source code files which doesn't matter much. I read something similar on Neovim's site, that they removed support of obsoleted architectures. And as an opposing example it seems that Linux kernel ships with drivers for very old devices and doesn't have plans for removing them. Note that I don't know if in xterm's or vim's case implementations for obsolete subsystems cause real damage or only increase code size. And when I was choosing a terminal implementation, I mostly benchmarked scrolling performance and looked at font rendering quality and xterm won. It is also actively maintained outside of Xorg [0]. [0] http://invisible-island.net/xterm/xterm.log.html http://invisible-island.net/xterm/xterm.log.html
- psibi 12y ago
  > Linux kernel ships with drivers for very old devices and doesn't have plans for removing them. I think as long as there is someone to maintain that driver, it doesn't get removed.
  - aartur 12y ago
    But if removing them would simplify other parts of code, I think they would do it, like they did for i386 recently.
    - systems_glitch 12y ago
      Indeed, they do remove truly unused architectures and drivers from the kernel -- support for IBM MicroChannel is gone, as well as support for "it was uncommon back then" hardware. I have a bunch of Allied Telesis ISA 10baseFL Ethernet cards that were recently removed.
- not_with_retard 12y ago
Aissen 12y ago
I personally love Terminology: https://www.enlightenment.org/p.php?p=about/terminology https://www.enlightenment.org/p.php?p=about/terminology It's modern, incredibly fast (could even be GPU-accelerated), fancy (if you want it to) and stable. See previous discussion: https://news.ycombinator.com/item?id=5438089 https://news.ycombinator.com/item?id=5438089
mahouse 12y ago
I like how he talks about bloated software and then uses Firefox.
johnchristopher 12y ago
My benchmark test for a terminal: If it takes more time for the graphical terminal to give me a usable prompt than alt+Fx then that particular terminal failed.
spain 12y ago
I feel stupid. I opened up the comments and then thought to myself "Hey, I remember reading a confession from the xterm developers themselves about how terribly bloated xterm is, I should go and find it again". After 5 minutes of searching I finally found it... Only it was on the suckless page for st.
humanrebar 12y ago
I like the idea of cleaning up legacy cruft. I'm not crazy about the way this project is going about it. My main issues: * ignoring C best practices: /* prefix macros, please */ #define MIN(a, b) ((a) < (b) ? (a) : (b)) * barely any comments /* ME: ...so it parses a string? Doesn't pretty * much every parser? Also, no prefix again. */ void strparse(void) { * Lack of overall project structure. Maybe some comments here would clear things up, but even some groupings like this would be nice: /************************* * X11 CALLBACKS GO HERE *************************/ * No tests. I think reasonable people can disagree about how testing should happen, but I'm a hard sell if you tell me your code needs absolutely no automated testing. If a new dev wants to commit a patch, how does she know her code works? * Here's a scenario broached by the README: One goal of st is to only support what is really needed. When you encounter a sequence which you really need, implement it. ...my problem is that there are no instructions here nor comments in the code about how start doing that ('see commit X in the repo' would even work). Again, I would hope that a dev-oriented tool like this (editing config.mk is in the installation instructions) would be a bit more friendly to developers who are stepping into the project for the first time. My concern is that the code might suck less than xterm (I'm not familiar with that code-base), but I'm not sure "less cruft" is a good enough reason for me to want to get involved with (or even use) a project. Of course, I'm willing for the people of suckless.org to prove me wrong in my assessment.
- tokenrove 12y ago
  strparse makes sense if you read the code linearly, since they also have csiparse, and deal with STREscape and CSIEscape, respectively. If you did need to add an escape sequence, it would take less than a minute to find where to add it. While I wouldn't call it a paragon of clarity, it basically follows the same style and organization as older Unix tools. In such cases, I find starting from main() and jumping around with ctags a useful strategy (after reading the globals and type definitions). Oh, and I strongly agree about tests. Especially escape sequence parsing could benefit from fuzzing or other property-based testing approaches.
  - humanrebar 12y ago
hibbelig 12y ago
How does copy and paste work with tmux in st? I guess it can't be marking with the mouse, for I can't imagine that tmux scrolls when I move the mouse downwards out of the window.
farresito 12y ago
The best terminal emulator I've used is termite[1]. It has vim-like keybindings and normal/insert mode, plus a bunch of other features worth looking at. If you are using xterm, urxvt, or something similar, I would highly suggest giving it a try. [1] https://github.com/thestinger/termite https://github.com/thestinger/termite
- gh02t 12y ago
  Termite is lovely. If you like it, you might also want to look at ROXTerm.
  - farresito 12y ago
    I'm a tmux user, so the menus and tabs are not really useful for me :). And the command mode in termite is vim oriented, so it's quite nice. I'm not sure how ROXTerm does it. To be honest, as long as a terminal supports vte (for fontconfig), it's already a huge improvement over xterm and urxvt.
    - gh02t 12y ago
      I'm a tmux user as well. I actually turn off all of the menus and make it pretty slimmed down. I stopped using Termite originally because colors were acting funky.
      - farresito 12y ago
        Interesting. Have you tried it lately? I've never had any problems in the past few months. If you are happy with whatever you are using now, then there is no need to change :).
- chanux 12y ago
  Since everyone is sharing their terminal emulator, I decided to hijack your comment and post mine :) . I use Sakura. https://launchpad.net/sakura https://launchpad.net/sakura
snarfy 12y ago
My friend tried committing code and getting involved, but they seem to be a tight-knit group of friends. It's hard for outsiders to do anything.
- exDM69 12y ago
  This may be true but it's also one of their goals not to really add new features. st and dwm both have some "3rd party" patches for some features that some people might want. I'm not sure whether that's the right thing to do but it's the way they work.
  - gh02t 12y ago
    I've used St and have written some patches myself to add minor features I wanted. I get the impression that they intend it to be a small core for people to add features themselves if they want. They implemented the core features that people can all agree on, then leave it as an exercise to the reader to add other stuff. Dwb follows a similar approach, I think. That said, I moved on to ROXterm because I was having encoding issues with a couple of programs I use. St is worth consideration as an uber-minimalist terminal though... it's very fast. Even on ancient hardware it launches essentially instantly because it's not loading any large libraries like GTK. St is pretty fun to hack on, too.
vortico 12y ago
To save others some time, they use X descriptors for font specifiers, like the following. st -f DejaVuSansMono-12
mzs 12y ago
I actually use xterm's tek4014 emulation for plots, I can keep them going off to the side at 15Hz just drawing over the top of each other until I change something in the main text window, then I erase and repeat. I tried to do similar with gnuplot but I could never figure-out how to keep updating continuously like that, so that's why.

92 points by cleverjake 12y ago

Xylemon 12y ago

Seems nice, however I do like the idea of a GTK2 based and tabbed terminal. Sadly, a lot of them feel very bloated.

exDM69 12y ago
st uses the Xembed protocol so you can use tabs with it using the "tabbed" utility from the same site (ie. you can embed many st instances into tabbed). Or just use tmux for "tabs", you'll need something like that anyway for scrollback, etc.
anoother 12y ago
evilvte

antirez 12y ago

Every software is a product, even if it is OSS and no money exchange is involved at all. There is a designer, and a final user. The idea of this product is that terminals don't need to scroll up into the past history, actually doing this well is one of the most critical aspects of a terminal as a good product for end users: retain history, do it reasonably when programs controlling the cursors are executed, don't get super slow if there is a lot of history already in memory, and so forth.

chriswarbo 12y ago
> actually [scrolling up] well is one of the most critical aspects of a terminal as a good product for end users You've clearly misunderstood the point st is trying to make. Not only is it not critical, it's a bad idea for a terminal to store and scroll history! Yes it's nice to have a history to scroll through, but other programs (screen, tmux, Emacs, etc.) are much better at doing that than terminal emulators are! For many people, like sysadmins, it's crucial that shells can be accessed over a network. Does that mean terminal emulators should build networking into their code? No, since SSH already does an excellent job. For many disabled people, it's crucial that shells can be speech-driven. Does that mean terminal emulators should build speech recognition into their code? No, since external systems (Sphinx, etc.) are already tackling this problem. Of course, from an "end user" perspective it would be nice to have "one application" which does all this. The beauty of the UNIX philosphy is that we can write such an application easily (untested, but you get the idea): #!/bin/sh if zenity --entry \ --title="New Terminal" \ --text="Enter the shell URL (blank for local shell)" \ then st -e "tmux -c ssh '$?'" else st -e "tmux" fi
- antirez 12y ago
  That's why I addressed it in the POV of a product. It's basically subjective. IMHO the "terminal product" should have history handling included.
  - chriswarbo 12y ago
    If you're thinking about a "terminal product" then why single out st's lack of history at all? That would be like claiming Excel lacks presentation capabilities. Whilst it's a true statement, presentation facilities are irrelevant to a spreadsheet; they're available in the PowerPoint component of the Microsoft Office suite, and they're designed to work together, so it's a complete non-issue.
fake-name 12y ago
You're entirely missing the point. Scrolling is already broken if you use any terminal multiplexer (such as `screen` or `tmux`). As such, having an additional, useless layer of scrollback on the client is both confusing and pointless, so they removed it.

stormbrew 12y ago

> Some random program complains that st is unknown/not recognised/unsupported/whatever! I really wish there was a better way to deal with this (I have the same problem with rxvt-unicode-256color). I'm obviously not going to make install a graphical terminal emulator on some random server I'm logging into.

vortico 12y ago
Put the following in your shell configuration. alias ssh='env TERM=xterm-256color ssh'
hoeppnertill 12y ago
tic -s st.info or setting your TERM variable should help.
- stormbrew 12y ago
  I meant the distribution problem of getting the file to the server. I grant that it's a petty annoyance, but it is still an annoying thing. And logging into a new server always carries with it the question of whether it's worth fixing it permanently when you barely use it. For the machines I regularly use I have terminfo files in my dotfiles git repo.
Sanddancer 12y ago
I'd argue that they should go the route that most terminal programs do and just announce they're xterm, or at least have a config file option for doing so.

AceJohnny2 12y ago

I like suckless. I use some of their tools within my Awesome(WM) sessions. However, I don't see the point of St. There are dozens of other graphical terminal emulators that were created with the exact same goal: "Xterm's codebase sucks, we can do better". FWIW, I've (currently[1]) settled on ROXTerm, which (on Debian and Ubuntu) comes in GTK2 and GTK3 variants. I use Tmux within it. It does FreeType and FontConfig fonts well, which I care strongly about. Its colour scheme is configurable and it's not tied to a desktop environment. It does use libvte from Gnome to implement the terminal emulator widget, and I'm OK with that. Less NIH please! [1] After using Gnome-Terminal, Konsole, and RXVT-Unicode for a while. I doubt my quest has yet ended.

e12e 12y ago
I've been using a few - in the end I landed on sakura: http://www.pleyades.net/david/projects/sakura http://www.pleyades.net/david/projects/sakura I don't quite remember why I ended up moving from urxvt to sakura (and not eg: roxterm) -- but I think it was a combination of it being light (enough), easy to set up without any kind of window decorations, as well as a sane way to pick and choose fonts. With the current gtk ~/.conf-scheme it has a nice ini-like config file, and I can easily have different font preferences on my laptop, my netbook and my desktop (all different screen sizes and different PPI). FFW I use a spartan xmonad setup, and typically run one, or a handful of terminal windows, each with their own gnu screen instance (typically one local, and a few remote screen instances over ssh. Sometimes I'll have more than one view/windows to one screen session -- and sometimes I might have a screen for a chroot or local vm/container of some sort).
- deleted 12y ago
  [deleted]
- emilburzo 12y ago
  Thanks for letting me know about sakura, I think it's the first one to actually match the rendering speed of xterm. I do have one question though, why are the colors more pale in sakura than in xterm? And is there any way to change it?

Zardoz84 12y ago

I use Konsole and yaquake always. Tabs, colors, profiles (I just have one for neovim), nice font rendering, split windows, copy&paste from clipboard... Apart, Windows needs a good terminal. Console2 and ConEmu, not end to work fine... I get strange issues with colors every time that I connect to ssh against a GNU/Linux machine and open vim.

RobinBlk7 12y ago
ConEmu works fine with colors. Your ssh client does not...
- Zardoz84 12y ago
  Yeah, I just learned that I should use ConEmu + Putty. At least now, I don't get weird colors and a grey background filling all when I open vim. But I keep missing having something like Yakuake or Konsole.
  - p8952 12y ago
    I use Mintty, the terminal which comes with Cygwin, and it works great both on Windows and while ssh'ed into Unix boxes. Windows + Vim: https://i.imgur.com/soTIhNy.png https://i.imgur.com/soTIhNy.png SSH + Vim: https://i.imgur.com/aLs9ACy.png https://i.imgur.com/aLs9ACy.png
shmerl 12y ago
Konsole is great.
davidgerard 12y ago
If I'm stuck on Windows, I just use a Cygwin console and ssh to the world.

otikik 12y ago

> xterm is bloated and unmaintainable. [...] It has over 65K lines of code and emulates obscure and obsolete terminals you will never need. The popular alternative, rxvt has only 32K lines of code. This is just too much for something as simple as a terminal emulator; it’s yet another example of code complexity. Ok, I am interested. > How do I scroll back up? > - Using a terminal multiplexer [shows tmux example] Emm... tmux is a 32K lines of code. That kind of defeats the purpose of the opening paragraph.

agumonkey 12y ago
I heard dtach + dvtm were smaller, but I'm not sure.
- chriswarbo 12y ago
  Nice, not seen dvtm before. Since I've not seen it mentioned in other multiplexer comparisons I was assuming it's not in major repos yet, but an optimistic "nix-env -i dvtm" has installed it!
  - agumonkey 12y ago
    nix really does make people optimistic
- not_with_retard 12y ago
  You should be using abduco instead of dtach now http://www.brain-dump.org/projects/abduco http://www.brain-dump.org/projects/abduco
klez 12y ago
I think the point is: do one thing and do it well. In this view, I guess it's not the terminal's duty to do multiplexing, scrolling etc. Tmux is meant to do the job, so its codebase size should not be added together with st's. They're separate software, each doing its thing and doing it well, an approach completely opposite to that of other software (e.g. emacs) that do lots of things.

erikb 12y ago

suckless sounds quite like a good name. I'm currently also working on some terminal style I/O and I can totally understand why there are programs with >30k lines of code just for being a terminal emulator. terminal communication is not really standardized. It has grown since a time where "computer" meant a person who calculates things. So I'm not sure it St could arrive at a stable state without also having a few thousands lines more than it would like to have. But what is wrong with Gnome-Terminal? For me it works well enough out of the box. I literally didn't do anything beside increasing the scroll buffer and haven't run into enough troubles yet to switch.

Argorak 12y ago
The source directory of libtsm, which only does the state handling for an abstract screen, is already ~11k without tests, so 30k doesn't surprise me. http://www.freedesktop.org/wiki/Software/kmscon/libtsm/ http://www.freedesktop.org/wiki/Software/kmscon/libtsm/
chriswarbo 12y ago
> But what is wrong with Gnome-Terminal? The dependencies: https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/gnome-3/3.12/core/gnome-terminal/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/g... If you're using Gnome, you probably have those already so it's no big deal. The same goes for Konsole in KDE: https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/kde-4.14/applications/konsole.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/desktops/k... If not, pulling in a few hundred MB of dependencies for a terminal emulator seems distasteful. st is much more self-contained: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/st/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio... That's why st is usually compared to xterm; they're small, basic and desktop-agnostic.
- erikb 12y ago
  That's good to know. Without Gnome(3) Gnome-Terminal might not be the right choice.

aartur 12y ago

> xterm is bloated and unmaintainable (...) It has over 65K lines of code and emulates obscure and obsolete terminals you will never need. The way these things are usually implemented is that there is an interface of a "terminal" and implementations. As long as implementations do not break the abstraction and do not require modifications in the interface and other parts of code these implementations do not decrease internal software quality. They only cause bloatedness in terms of size of source code files which doesn't matter much. I read something similar on Neovim's site, that they removed support of obsoleted architectures. And as an opposing example it seems that Linux kernel ships with drivers for very old devices and doesn't have plans for removing them. Note that I don't know if in xterm's or vim's case implementations for obsolete subsystems cause real damage or only increase code size. And when I was choosing a terminal implementation, I mostly benchmarked scrolling performance and looked at font rendering quality and xterm won. It is also actively maintained outside of Xorg [0]. [0] http://invisible-island.net/xterm/xterm.log.html http://invisible-island.net/xterm/xterm.log.html

psibi 12y ago
> Linux kernel ships with drivers for very old devices and doesn't have plans for removing them. I think as long as there is someone to maintain that driver, it doesn't get removed.
- aartur 12y ago
  But if removing them would simplify other parts of code, I think they would do it, like they did for i386 recently.
  - systems_glitch 12y ago
    Indeed, they do remove truly unused architectures and drivers from the kernel -- support for IBM MicroChannel is gone, as well as support for "it was uncommon back then" hardware. I have a bunch of Allied Telesis ISA 10baseFL Ethernet cards that were recently removed.
not_with_retard 12y ago

Aissen 12y ago

I personally love Terminology: https://www.enlightenment.org/p.php?p=about/terminology https://www.enlightenment.org/p.php?p=about/terminology It's modern, incredibly fast (could even be GPU-accelerated), fancy (if you want it to) and stable. See previous discussion: https://news.ycombinator.com/item?id=5438089 https://news.ycombinator.com/item?id=5438089

mahouse 12y ago

I like how he talks about bloated software and then uses Firefox.

johnchristopher 12y ago

My benchmark test for a terminal: If it takes more time for the graphical terminal to give me a usable prompt than alt+Fx then that particular terminal failed.

spain 12y ago

I feel stupid. I opened up the comments and then thought to myself "Hey, I remember reading a confession from the xterm developers themselves about how terribly bloated xterm is, I should go and find it again". After 5 minutes of searching I finally found it... Only it was on the suckless page for st.

humanrebar 12y ago

I like the idea of cleaning up legacy cruft. I'm not crazy about the way this project is going about it. My main issues: * ignoring C best practices: /* prefix macros, please */ #define MIN(a, b) ((a) < (b) ? (a) : (b)) * barely any comments /* ME: ...so it parses a string? Doesn't pretty * much every parser? Also, no prefix again. */ void strparse(void) { * Lack of overall project structure. Maybe some comments here would clear things up, but even some groupings like this would be nice: /************************* * X11 CALLBACKS GO HERE *************************/ * No tests. I think reasonable people can disagree about how testing should happen, but I'm a hard sell if you tell me your code needs absolutely no automated testing. If a new dev wants to commit a patch, how does she know her code works? * Here's a scenario broached by the README: One goal of st is to only support what is really needed. When you encounter a sequence which you really need, implement it. ...my problem is that there are no instructions here nor comments in the code about how start doing that ('see commit X in the repo' would even work). Again, I would hope that a dev-oriented tool like this (editing config.mk is in the installation instructions) would be a bit more friendly to developers who are stepping into the project for the first time. My concern is that the code might suck less than xterm (I'm not familiar with that code-base), but I'm not sure "less cruft" is a good enough reason for me to want to get involved with (or even use) a project. Of course, I'm willing for the people of suckless.org to prove me wrong in my assessment.

tokenrove 12y ago
strparse makes sense if you read the code linearly, since they also have csiparse, and deal with STREscape and CSIEscape, respectively. If you did need to add an escape sequence, it would take less than a minute to find where to add it. While I wouldn't call it a paragon of clarity, it basically follows the same style and organization as older Unix tools. In such cases, I find starting from main() and jumping around with ctags a useful strategy (after reading the globals and type definitions). Oh, and I strongly agree about tests. Especially escape sequence parsing could benefit from fuzzing or other property-based testing approaches.
- humanrebar 12y ago

hibbelig 12y ago

How does copy and paste work with tmux in st? I guess it can't be marking with the mouse, for I can't imagine that tmux scrolls when I move the mouse downwards out of the window.

farresito 12y ago

The best terminal emulator I've used is termite[1]. It has vim-like keybindings and normal/insert mode, plus a bunch of other features worth looking at. If you are using xterm, urxvt, or something similar, I would highly suggest giving it a try. [1] https://github.com/thestinger/termite https://github.com/thestinger/termite

gh02t 12y ago
Termite is lovely. If you like it, you might also want to look at ROXTerm.
- farresito 12y ago
  I'm a tmux user, so the menus and tabs are not really useful for me :). And the command mode in termite is vim oriented, so it's quite nice. I'm not sure how ROXTerm does it. To be honest, as long as a terminal supports vte (for fontconfig), it's already a huge improvement over xterm and urxvt.
  - gh02t 12y ago
    I'm a tmux user as well. I actually turn off all of the menus and make it pretty slimmed down. I stopped using Termite originally because colors were acting funky.
    - farresito 12y ago
      Interesting. Have you tried it lately? I've never had any problems in the past few months. If you are happy with whatever you are using now, then there is no need to change :).
chanux 12y ago
Since everyone is sharing their terminal emulator, I decided to hijack your comment and post mine :) . I use Sakura. https://launchpad.net/sakura https://launchpad.net/sakura

snarfy 12y ago

My friend tried committing code and getting involved, but they seem to be a tight-knit group of friends. It's hard for outsiders to do anything.

exDM69 12y ago
This may be true but it's also one of their goals not to really add new features. st and dwm both have some "3rd party" patches for some features that some people might want. I'm not sure whether that's the right thing to do but it's the way they work.
- gh02t 12y ago
  I've used St and have written some patches myself to add minor features I wanted. I get the impression that they intend it to be a small core for people to add features themselves if they want. They implemented the core features that people can all agree on, then leave it as an exercise to the reader to add other stuff. Dwb follows a similar approach, I think. That said, I moved on to ROXterm because I was having encoding issues with a couple of programs I use. St is worth consideration as an uber-minimalist terminal though... it's very fast. Even on ancient hardware it launches essentially instantly because it's not loading any large libraries like GTK. St is pretty fun to hack on, too.

vortico 12y ago

To save others some time, they use X descriptors for font specifiers, like the following. st -f DejaVuSansMono-12

mzs 12y ago

I actually use xterm's tek4014 emulation for plots, I can keep them going off to the side at 15Hz just drawing over the top of each other until I change something in the main text window, then I erase and repeat. I tried to do similar with gnuplot but I could never figure-out how to keep updating continuously like that, so that's why.