Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

St – simple terminal

st.suckless.org

Post reply on HN
Print view View original

61–70 of 88 posts

Re: St – simple terminal

#61

Post by humanrebar »

tokenrove wrote: post #56
humanrebar wrote: post #51

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) * 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…

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…

  ...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, I know it's the same style and organization as older Unix tools. And it's the same style and organization as large one-off perl scripts. It would be a shame to replace old cruft with new stuff that doesn't the leverage lessons learned in software engineering over the last 40 years or so.

Re: St – simple terminal

#62

Post by antirez »

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.

Re: St – simple terminal

#63

Post by gh02t »

exDM69 wrote: post #60
snarfy wrote: post #58

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.

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.

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.

Re: St – simple terminal

#64

Post by gh02t »

farresito wrote: post #55

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

Termite is lovely. If you like it, you might also want to look at ROXTerm.

Re: St – simple terminal

#65

Post by chriswarbo »

boomlinde wrote: post #52
chriswarbo wrote: post #37

Earlier quoted context omitted.

Terminal emulators accept drawing commands (literal and control characters) and render them to some kind of device (eg. a framebuffer, an X window, a Wayland surface, etc.). Multiplexers accept drawing commands from multiple applications and combine them into one "root window". By analogy, Linux launches a single process (init) which then handles all the others. The init system is not a kernel. On the other hand, X11…

> Terminal emulators accept drawing commands (literal and control characters) and render them to some kind of device (eg. a framebuffer, an X window, a Wayland surface, etc.). Multiplexers accept drawing commands from multiple applications and combine them into one "root window". If we accept for the sake of discussion that rendering to a "device" is the distinguishing characteristic of terminal emulators here, rathe…

> If we accept for the sake of discussion that rendering to a "device" is the distinguishing characteristic of terminal emulators here, rather than, say, emulating terminals (which tmux certainly does), can't you think of another terminal emulator as such a device?

It depends whether you think "Save to PDF" printer drivers really are printing. Does tmux "certainly" emulate a terminal, given that I can't observe any of the output or send it any input without assistance from another terminal emulator, like st?

> I can't really tell how the Linux init analogy is valid and what your point of making it is. Is the init system a "kernel emulator" or a "kernel multiplexer"?

The init system is like a "process multiplexer". The kernel only starts one process; if we tell it to start bash, we have a shell but not much else (until we fork stuff off manually). If we tell it to start an init system/daemon then we get a whole bunch of processes started for us during boot.

Likewise, when we start a terminal emulator we can run bash to get a single shell session, or we can run a multiplexer to get many.

Re: St – simple terminal

#66

Post by boomlinde »

klez wrote: post #19
boomlinde wrote: post #17

Earlier quoted context omitted.

I'm not sure in what meaningful sense of the word tmux isn't also a terminal emulator, thus doing more than it should, if I follow your reasoning all right.

Fair enough, in a way, but I'd say you can't launch it stand-alone inside an X session without using another terminal emulator (st, xtrem, whatever).

That is true. It seems somewhat beside your original point, though, unless you are arguing that that difference cuts it clear which terminal emulator should handle scrollback

Re: St – simple terminal

#67

Post by chanux »

farresito wrote: post #55

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

Since everyone is sharing their terminal emulator, I decided to hijack your comment and post mine :) .

I use Sakura. https://launchpad.net/sakura

Re: St – simple terminal

#68

Post by klez »

boomlinde wrote: post #66
klez wrote: post #19

Earlier quoted context omitted.

Fair enough, in a way, but I'd say you can't launch it stand-alone inside an X session without using another terminal emulator (st, xtrem, whatever).

That is true. It seems somewhat beside your original point, though, unless you are arguing that that difference cuts it clear which terminal emulator should handle scrollback

No, my point wasn't strictly about scrolling. My line of reasoning is:

1 tmux is needed to handle multiplexing

2 tmux also handles scrolling

3 if you need tmux for other things already, you don't need scrolling in the terminal emulator

I wouldn't say that, by this reasoning, it is the right place to implement scrolling, just that, since it's a solved problem, re-implementing it would be a useless duplication of effort.

But in this specific case I'd concede that the way tmux scrolls is not at all comparable with how a X terminal emulator would be expected to scroll.

Re: St – simple terminal

#69

Post by chriswarbo »

antirez wrote: post #62

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…

> 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

Re: St – simple terminal

#70

Post by antirez »

chriswarbo wrote: post #69
antirez wrote: post #62

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…

> 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!…

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.
Post reply on HN