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

St – A simple terminal implementation for X

st.suckless.org

Post reply on HN
Print view View original

181–190 of 223 posts

Re: St – A simple terminal implementation for X

#181

Post by kedean »

wruza wrote: post #81
donatj wrote: post #55

Earlier quoted context omitted.

I second this out of true curiosity. I have tried and never found any love in my heart for iTerm2. It just feels clunky and bloated to me.

Last time I asked, someone said: "many features, but I like cmd-click to open path". After reading [1] I see that all it does is loading hipster-oriented "features" into your brain. Almost every feature is useless if you're doing any amount of actual work with decent cli tools. But for playing a hacker it is pretty cool. [1] https://www.iterm2.com/features.html

There's nothing wrong with features that give you access to the wider operating system. Like it or not, the modern operating system is more than just terminals and CLI tools, and there's no reason to be condescending to those who don't live exclusively in the terminal.

A large part of what makes iTerm2 popular is how well it works in tandem with MacOS. Things like cmd+click to open (useful because you can use it on data that was spat out from a previous command invocation), paste filtering, and the fantastic built-in multiplexer/tabbing system.

That said, most of what makes MacOS users like iTerm2 just wouldn't be as useful on any other operating system, because its so tightly coupled to the wider OS.

Re: St – A simple terminal implementation for X

#182

Post by lvh »

davidshepherd7 wrote: post #169
nine_k wrote: post #116

Earlier quoted context omitted.

You can run a completely unscientific experiment yourself: take a really large text file, or just use `yes`, and time its full output on several different terminals. yes | head -n 1000000 > two_megs.txt time cat two_megs.txt You will definitely see a difference in the time it takes to complete or a libvte-based terminal, xterm, urvxt, roxterm, etc. OTOH I can google up posts saying that pt shows good results in compa…

Huh, interesting results on my machine: urxvt 0.233 gnome 0.474 st 0.515 xterm 1:13.87 times are total real time, in seconds, seem repeatable from a few runs. I was expecting st to blow everything else away given its focus on minimalism, and what the hell is going on with xterm?

Minimalism is a tempting proxy for performance, but it often isn't. rg/ag/pt aren't some of the fastest file searchers around because they're short and don't pull cool tricks.

Another example: GNU vs BSD grep, from the author's mouth: https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...

Regex matching: https://swtch.com/~rsc/regexp/regexp1.html

(It's arguable that a backtracking implementation is not the simplest, although I think it is -- and even if it is, a FSA compiler clearly isn't!)

And, finally: people tell me Clojure is slow, and I tell them that it lets me write correct concurrent algorithms I understand. (See alioth shootout results.)

Re: St – A simple terminal implementation for X

#184

Post by sime2009 »

unfamiliar wrote: post #34

I find terminal emulators on Linux to be woefully inadequate after getting used to iTerm2 on OS X. Can anyone recommend a Linux terminal emulator that even comes close in terms of features and performance?

I'm working on a new terminal which takes a few cues from iTerm2 and also adds other unique features. It is not up to production level quality like iTerm2 but you are more than welcome to try it out.

Extraterm -> https://github.com/sedwards2009/extraterm

The visual tour page explains some of the ideas present. https://github.com/sedwards2009/extraterm/blob/master/docs/t...

Re: St – A simple terminal implementation for X

#185

Post by sevensor »

dedsm wrote: post #149
loup-vaillant wrote: post #121

Earlier quoted context omitted.

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.

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

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.

Re: St – A simple terminal implementation for X

#186

Post by bitwize »

davidshepherd7 wrote: post #169
nine_k wrote: post #116

Earlier quoted context omitted.

You can run a completely unscientific experiment yourself: take a really large text file, or just use `yes`, and time its full output on several different terminals. yes | head -n 1000000 > two_megs.txt time cat two_megs.txt You will definitely see a difference in the time it takes to complete or a libvte-based terminal, xterm, urvxt, roxterm, etc. OTOH I can google up posts saying that pt shows good results in compa…

Huh, interesting results on my machine: urxvt 0.233 gnome 0.474 st 0.515 xterm 1:13.87 times are total real time, in seconds, seem repeatable from a few runs. I was expecting st to blow everything else away given its focus on minimalism, and what the hell is going on with xterm?

It could have to do with that xterm is trying to faithfully emulate an actual terminal (viz., VT220 with extensions) by replicating the VT's internal state machine, whereas libvte is trying to approximate the behavior of xterm and cutting corners as it does so.

Note that while libvte seems to have greater throughput, its latency is terrible compared to xterm.

Re: St – A simple terminal implementation for X

#187

Post by fpqc »

fiddlerwoaroof wrote: post #27
aidenn0 wrote: post #23

Earlier quoted context omitted.

And I want to paste it into a non-terminal application running locally while the tmux is on a remote host?

You can always use ssh and something like xclip or pbcopy. 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.

I just added a feature to tmux-git that makes the tmux clipboard propagate up into higher clipboards for nested tmux. https://github.com/tmux/tmux/commit/4ede35c48c089abe3fca0d94...

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.

Re: St – A simple terminal implementation for X

#188

Post by pmoriarty »

wruza wrote: post #81
donatj wrote: post #55

Earlier quoted context omitted.

I second this out of true curiosity. I have tried and never found any love in my heart for iTerm2. It just feels clunky and bloated to me.

Last time I asked, someone said: "many features, but I like cmd-click to open path". After reading [1] I see that all it does is loading hipster-oriented "features" into your brain. Almost every feature is useless if you're doing any amount of actual work with decent cli tools. But for playing a hacker it is pretty cool. [1] https://www.iterm2.com/features.html

I don't know if the "cmd-click to open path" is a feature that's already built in to any Linux terminal (though I wouldn't be at all surprised if it was, considering how many terminals Linux has).

You can probably do something like it with urxvt's perl extensions. You could also just double-click to copy the path to the X primary selection and then use a keyboard macro to open the path in the primary selection in your file browser, or whatever.

Re: St – A simple terminal implementation for X

#189

Post by pmoriarty »

itsadok wrote: post #87
pmoriarty wrote: post #36

Earlier quoted context omitted.

What features do you need in iTerm2 that you find lacking in the Linux terminal emulators you've tried?

Not OP, but some cool features I haven't seen in Linux: - Quadruple-click smart selection - "Selection respects soft boundaries" for selecting within a tmux pane - "Rum coprocess" on keyboard shortcut, which allows doing stuff like http://brettterpstra.com/2014/11/14/safer-command-line-paste... I just checked, and gnome-terminal doesn't even have split-pane. What do you guys use, anyway?

Quadruple-click smart selection should be doable with urxt's perl extension feature.

Selecting within a tmux pane: you got me on that one. I'm not aware of a terminal that does that, but again, it should be possible to do with urxvt's perl extension feature.

Regarding the "safer command line paste", Linux can do the same with bracketed paste mode.[1]

For splitting panes, I just use tmux, vim, or emacs.

[1] - https://cirw.in/blog/bracketed-paste

Re: St – A simple terminal implementation for X

#190

Post by fpqc »

aidenn0 wrote: post #78
jdormit wrote: post #46

Earlier quoted context omitted.

'xclip -selection clipboard' works fine for this use case. [Edit] Assuming you have SSH configured to forward to your local X server [0]. [0] http://unix.stackexchange.com/a/16697

Unfortunately many ssh servers gratuitously disallow X11 forwarding; tcp forwarding can accomplish the same, but then setting up DISPLAY &ct. need to be done manually.

In the latest git builds of tmux (with the latest terminfo db from ncurses), you can have clipboards propagate from remote tmux to local tmux (nested configuration) using the new OSC52 control sequence implemented in a patch from 2 weeks ago.

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.

Post reply on HN