terminal

Another positive variation of saying thanks is bringing to attention a great feature of a tool. The authors of the tool might not be aware at how impactful a feature is and if something like that gets enough upvotes / love then it could help prevent regressions or the feature disappearing at a later point in time. It also lets the authors know you care (see the first reply below). For example: https://github.com/microsoft/terminal/issues/327

It seems nice but using WSL(2) Windows Terminal is noticeably faster for me, same compared to most other alternatives including Cmder/ConEmu. While Windows Terminal doesn't have a settings UI (yet[0]) it does allow for theming, this page[1] features a range of color schemes that you can define and set in your settings.json. There's also a wrapper that allows for quake style drop down [2] until it's implemented by Windows Terminal itself[0]. [0] https://github.com/microsoft/terminal/blob/main/doc/terminal... [1] https://windowsterminalthemes.dev/ [2] https://github.com/flyingpie/windows-terminal-quake

FWIW, why the Windows Terminal is so responsive from its collaborator: https://github.com/microsoft/terminal/issues/327#issuecommen... This was posted here few times but it's still an interesting read in this context.

What do you mean? It looks normal to me. Do you mean the blocks here? https://github.com/microsoft/terminal/blob/main/src/renderer...

The whole Terminal code is open source https://github.com/microsoft/terminal/blob/main/src/renderer... The first comment in this function (DxEngine::StartPaint), for example: // If retro terminal effects are on, we must invalidate everything for them to draw correctly. // Yes, this will further impact the performance of retro terminal effects. // But we're talking about running the entire display pipeline through a shader for // cosmetic effect, so performance isn't likely the top concern with this feature.

- ui to configure options. currently it is editing json - back then i was missing, pane zoom (only recently got added). - looking at the docs, i think cycling through zoomed / unzoomed panes is stil not yet there. i might be wrong. - configuring how the split lines looks of the terminal. - moving panes to other tabs found the ticket around panes: https://github.com/microsoft/terminal/issues/1000 there is quite some todo left.

It is not the way that every other terminal, or indeed terminal emulator, works; nor is it relied upon by "everyone". For starters: Softwares that use terminfo, and anything built on top of it such as ncurses, only use this for one specific terminal type, linux-16color. No other terminal type in terminfo changes colour this way. The idea that boldface and blink change colours has been on its way out since the 1990s. XTerm has had the ability since 1997; and while its XTerm personality does not, its UXTerm personality defaults to boldface meaning boldface. Of course AIXterm, at the start of the 1990s, had SGRs 90 to 97 and 100 to 107, and did 16 colours that way, not with boldface. The Windows Terminal issue shows some of how far this notion has extended in the more than a quarter of a century since. It isn't a VGA world any more, and

Other seemingly more minor (but which will possibly be more widely used eventually) features are different forms of underline, selectable through sub-parameters to SGR 4. I've already put this into my terminal emulator, although that version is not released yet; it exists in LibVTE and several other terminal emulators; and the Windows Terminal people also have a backlog item for it. * https://github.com/microsoft/terminal/issues/7228

For what it's worth: The issue about bold and blink performing colour changes is widespread across terminal emulators. It has come up for Windows Terminal, for example, and the libVTE people have already addressed this. In reality, the only terminfo entry that even does this any more is the linux-16color one for the built-in Linux terminal emulator. There's a sea change happening here. It's a post-VGA world. Boldface means boldface. * https://github.com/microsoft/terminal/issues/5682

try Windows Terminal https://aka.ms/terminal https://github.com/Microsoft/Terminal

No experience with Conemu and WSL, but Windows Terminal [1] provides smooth experience. WSL2 has a completely new approach than WSL1, so compatibility is better. [1] https://github.com/microsoft/terminal

I'd be curious to see how this plays out. > We expect real-time collaboration to dominate future markets as the pandemic runs its course and forces people and businesses online en masse I'd think that the area for the easiest investment in this problem space wouldn't be on the creation of a new terminal emulator (like iTerm2 or the Windows Terminal), but instead as a piece of software running on the remote server, something like tmux. Imagine instead a tmux that could allow multiple users to connect to it simultaneously, and drive different panes at the same time, or view the commands that another user is using in a given pane. Then, regardless of what terminal emulator you choose, you'd be able to collaborate with your teammates, once you connect to the same server session. When I think about a "Terminal 2.0", I imagine something more li

Another option worth trying is Microsoft's Windows Terminal. https://github.com/microsoft/terminal

The issue with everything which is not PuTTY is terminal emulation bugs, in my experience. I’ve never experienced one in PuTTY or at least not noticeably. Whereas using SSH in every other Windows terminal (including the newer windows terminal emulator they’ve been working on), I eventually run into display bugs requiring me to refresh the terminal somehow, particularly in long running tmux sessions. I believe they will get there with Windows terminal (https://github.com/Microsoft/Terminal), I just don’t think they are there yet.