Personally I am enjoying terminology very much. https://www.enlightenment.org/about-terminology
Sadly Terminology doesn't have support for 24bit RGB sequences (true color): https://gist.github.com/XVilka/8346728
St – A simple terminal implementation for X
61–70 of 223 posts
Re: St – A simple terminal implementation for X
#62I can't help myself: suckless sucks. Lots of arbitrary limitations for the code, need to recompile instead of configuration, optimizing for a wrong usage scenario.
Re: St – A simple terminal implementation for X
#63Earlier quoted context omitted.
Bugs. When you work all day long in a terminal, you need it to be reliable. As I mentioned above, xfce4-terminal is what I normally use but select-to-copy doesn't work 100% of the time. This is super annoying. I'd switch to rxvt but it has its own problems. Despite having had terminals for so much longer, *nix has fallen behind macOS when it comes to terminal usability and reliability.
Termite is pretty good and bug-free in my experience.
Plug: I maintain a fork of termite which doesn't require Daniel's patched VTE3 fork; and guts most of the exotic vimmy features.
I really like VTE's behaviour; even if the performance is a bit worse than XTerm (though worlds ahead of what I've seen on OSX with iTerm2 and Terminal.app). I rely on using iBus input methods in the terminal on a daily basis, and VTE handles this wonderfully.
Re: St – A simple terminal implementation for X
#64Interesting. I've been wanting a better terminal for some time. rxvt is super buggy, especially with clickable URLs. xfce4-terminal is better but select-to-copy is flaky and doesn't always copy the text I select. I really wanted st to work for me but something is wrong with the character sizing when using Source Code Pro (17pt) as the font. I installed this on my Arch laptop (a hidpi ThinkPad T460s) and something is…
> rxvt is super buggy Which one are you using? AFAIK urxvt is the only maintained fork. I could be wrong. > I would report this to the author but I don't see any way to do so. http://suckless.org/community
You'll probably get yelled at to fix your font config if you report it, though.
They're pretty big on "This is not #support. Post patch or GTFO" last I was there.
Re: St – A simple terminal implementation for X
#65I 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 was always happy with gnome-terminal.
But then someone recommended Terminator and haven't gone back since :) It feels like gnome-terminal on steroids. Love the multipane stuff.
Re: St – A simple terminal implementation for X
#66I 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?
rxvt-unicode (urxvt)?
Re: St – A simple terminal implementation for X
#67> xterm is bloated and unmaintainable.
which is why I use rxvt-unicode
Re: St – A simple terminal implementation for X
#68I can't help myself: suckless sucks. Lots of arbitrary limitations for the code, need to recompile instead of configuration, optimizing for a wrong usage scenario.
You're clearly not their target audience if those are your takeaways. But there are lots of people out there who do prefer to recompile instead of configure and find suckless feature sets to be inline with their own requirements. To say that a product "sucks" because they don't cater specifically to your arbitrary desires is grossly unfair.
Re: St – A simple terminal implementation for X
#69Earlier quoted context omitted.
Different people want different features. There's no way they're going to remain minimal and please everyone. They have to choose the feature set, and if other programs can provide a feature that some users want, that seems like a feature ripe for pruning. I think they made the right choice.
I always find tmux's scrollback to be vastly inferior to a native terminal's though. There are several reasons, but the biggest is that I'm pretty sure it's not possible to get more than a screenfull of text to my local X11 PRIMARY selection.
And it's slow.
Re: St – A simple terminal implementation for X
#70Recompiling software to change options is utterly and totally ridiculous
Not that ridiculous from a developers perspective. All of the software I write use hardcoded constants as config. Then once the app is stable and usable by myself on production environments - and only at that point - do I consider building in a config system or at least a few command line flags.
What's more, many developers (myself included) aren't afraid of jumping into someone elses code and modifying it to behave how we want.
Let's also remember that a great deal of software you don't even think about also runs this way; they'll have config flags to add and remove features at compile time (run Gentoo or FreeBSD ports for a few weeks and you'll see what I mean).
So having hardcoded options isnt that ridiculous nor uncommon on Linux. However mainstream desktop distros do a good job at hiding that from their users by picking sane defaults for them.