Earlier quoted context omitted.
Have you heard of nohup?
Sure. But nohup doesn't work for shells or anything interactive. You can't attach to it.
Although you could ditch it and use MOSH instead.
411–420 of 491 posts
Earlier quoted context omitted.
Have you heard of nohup?
Sure. But nohup doesn't work for shells or anything interactive. You can't attach to it.
Although you could ditch it and use MOSH instead.
How do they define performance, and how do they measure it?
Some terminals bottleneck standard out ️ display , some hardcode the display rate
Not sure why they rebuilt a clipboard library when "clipboard" exists (I think it might even be used within Servo, not sure): https://crates.io/crates/clipboard
> A non-GPL licensed cross-platform clipboard library, (That is, that project is GPL licensed, and they didn't want that)
Thanks for your help, Steve !
Earlier quoted context omitted.
> I respectfully disagree. Alacritty follows the Unix philosophy of doing one thing, and doing it well. I used to think that terminal scrollback and tabs were great ideas -- but switching to tmux changed my mind completely. Tmux is so much more capable for managing your session history. The terminal's tab and scrollback features can never match this. They're just bloat :p This is the problem of Unix philosophy, becau…
> Adding tmux just to get scrollback goes against Unix philosophy. I agree. Rather than adding scrollback support to allacritty, maybe someone could write an independent program for scrollback support (a la dtach/abduco for detaching/reattaching)? Such a program would be useful for all terminals which lack scrollback (alacritty, st, possibly others). For the record I use st with dtach and dvtm; scrollback is supplied…
Earlier quoted context omitted.
> Personally, the lack of scrollback and tabs is a dealbreaker for me Completely understandable. This decision was expected to be polarizing. > Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux. Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone.
I like opinionated software. If scrollback is better implemented on a different layer, leaving it out is reasonable. But I'm not using tmux because I use i3 as wm which does all the tiling/splitting. Now using a new tmux instance for each of my terminal (can be dozens) only for scrollback seems not the right way though. Any recommendations what would be The Right Way here? Anything that only implements scrollback may…
Earlier quoted context omitted.
> You do seem overly excited. :) Hah, yeah I'm aware, but the potential of Rust is huge. We talk a lot about open source these days, but meanwhile the tools that we all use are sitting on huge substrates that the vast majority of us aren't contributing to and probably never will due to the complexity hurdle that needs to be overcome. This includes our web browsers, our terminals, our editors/IDEs, our operating syste…
Isnt most of your points just the relative newness of rust? I could rewind a few years, replace [rust] with other platforms like [node] or [erlang] and the same statements apply. I'm not disagreeing with you, I'm just pointing out that it seems to be the stage an a natural progression of platforms.
What a decent terminal emulator should have is standard compliance and decent font rendering (and freetype is good-enough).
Lousy engineering will lead to lousy code, especially when the main objective is to show off (engineering is, obviously, not an objective.) Btw, using Rust is not an engineering.
While GPU accelerated 3D interfaces (like it in 3D games) is a good idea (at least one could mix data visualization and with controls - the way WebGL guys do it) a terminal emulator does not require any acceleration, leave alone having a Nvidia drivers or Cuda as a dependency. What a decent terminal emulator should have is standard compliance and decent font rendering (and freetype is good-enough). Lousy engineering…
While GPU accelerated 3D interfaces (like it in 3D games) is a good idea (at least one could mix data visualization and with controls - the way WebGL guys do it) a terminal emulator does not require any acceleration, leave alone having a Nvidia drivers or Cuda as a dependency. What a decent terminal emulator should have is standard compliance and decent font rendering (and freetype is good-enough). Lousy engineering…
Everything that can be GPU-accelerated should be GPU-accelerated. The GPU is far more energy efficient, and every bit of offload onto the GPU leads to a decrease in CPU consumption. Terminals can be particularly CPU-heavy when running a chatty program.