Live data from Hacker News

St – simple terminal

st.suckless.org

51–60 of 88 posts

Re: St – simple terminal

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

Re: St – simple terminal

#52

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.

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, rather than, say, emulating terminals (which tmux certainly does), can't you think of another terminal emulator as such a device?

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"?

Re: St – simple terminal

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

Re: St – simple terminal

#54
post #36

Earlier quoted context omitted.

I've used gnome-terminal, sakura and now I'm using terminator: http://gnometerminator.blogspot.co.uk/p/introduction.html The main difference with the other terminal emulators is that I can easily do horizontal and vertical window splits. Many use screen or tmux for that but I find them too limiting, especially in their scrollback implementation.

i always found screen splitting in the terminal when you have a graphical window manager kinda of silly.

I tend to have terminator fullscreened (no decorations) on one desktop, and switch desktops far more often than I switch windows.

Re: St – simple terminal

#56

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

Re: St – simple terminal

#57
post #36

Earlier quoted context omitted.

i always found screen splitting in the terminal when you have a graphical window manager kinda of silly.

I'd love it if there would be graphical frontend to tmux or screen. Something that would look very much like a terminal emulator, with tabs and splits, but backed by screen or tmux, whereby each tab or split window would be a tmux or screen window. And the awesome part is that when you're elsewhere, you could ssh in and attach to that tmux or screen session.

You can do that on OS X with iTerm2 e.g.: http://www.railsonmaui.com/blog/2014/03/11/rocking-with-tmux...

Re: St – simple terminal

#59
post #18

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

> But what is wrong with Gnome-Terminal? The dependencies: 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/k... If not, pulling in a few hundred MB of dependencies for a terminal emulator seems distasteful. st is much more self-contain…

That's good to know. Without Gnome(3) Gnome-Terminal might not be the right choice.

Re: St – simple terminal

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

Post reply on HN