Implement DECSLRM and DECLRMM

[kevinburke]

From the README:

macOS + tmux + vim is slow! I thought this was supposed to be fast! This appears to be an issue outside of terminal emulators; either macOS has an IPC performance issue, or either tmux or vim (or both) have a bug. This same issue can be seen in iTerm2 and Terminal.app. I've found that if tmux is running on another machine which is connected to Alacritty via SSH, this issue disappears. Actual throughput and rendering performance are still better in Alacritty.

I'm creating this issue so we can track the progress of finding/fixing the issue in question.

[nemtsov]

I'm very interested in this issue, and would love to help debug it. Is there any anyformation about my system that would be useful to repro?

For me the slowness appears when opening a split (with NERDTree) and attempting to scroll. The FPS appears to drop dramatically. It's significantly slower than in iTerm. Scrolling when a split is closed is faster than in iTerm, on the other hand.

[jwilm]

There's an issue on the Node.js issue tracker that sounds like it may be related. I have not put thought into how it relates to Alacritty's fork/exec.

[terryma]

This unfortunately makes vim inside tmux unusable for me. Whenever I have a split open, scrolling grinds my machine to a halt. Anything I can provide to help troubleshoot this would be great. I've been very happy with the experience so far, and this issue along with font fallback are the only things missing for me. Thanks for your great work!

[jwilm]

Perf should be a lot better as of tmux version 2.5. The only thing Alacritty can do to make this better is add support for DECSLRM.

[nicm]

DECSLRM makes a huge difference to iTerm2. Terminal.app is the same so it does seem that perhaps OS X has some performance issues with large volumes of data over the network, or interacts poorly with tmux's backoff scheme. DECSLRM helps on any platform when using tmux over a network however, even if not so dramatically.

If you implement it, I would encourage you to also implement DSR 1337 like iTerm2 so that tmux can use this to detect Alacritty and enable the feature - the only other way for it to detect it is to look for the VT420 response from DA and I doubt you want that unless you are also going to add the other VT420 features (some of them slightly strange):

$ printf '\033[1337n';cat
^[[ITERM2 3.3.20200112-NIGHTLYn

[chrisduerr]

textshell has shared some good information on what edgecases have to be considered to implement this: mintty/mintty#881 (comment)

[christianparpart]

DECSLRM makes a huge difference to iTerm2. Terminal.app is the same so it does seem that perhaps OS X has some performance issues with large volumes of data over the network, or interacts poorly with tmux's backoff scheme. DECSLRM helps on any platform when using tmux over a network however, even if not so dramatically.

If you implement it, I would encourage you to also implement DSR 1337 like iTerm2 so that tmux can use this to detect Alacritty and enable the feature - the only other way for it to detect it is to look for the VT420 response from DA and I doubt you want that unless you are also going to add the other VT420 features (some of them slightly strange):

$ printf '\033[1337n';cat
^[[ITERM2 3.3.20200112-NIGHTLYn

Instead of that, why not just usingXTVERSION? I am just dropping by and left my taughts here. Check notcurses for good use of that as well as to see who else is implementing that.

Cheers.

[j4james]

Just FYI, there is an official extension number in the DA1 response for identifying this capability: 21 (Horizontal Scrolling). That assumes you're supporting all of the required sequences in that extension, though, which I think includes DECSLRM, DECLRMM, DECFI, DECBI, DECIC, and DECDC. It doesn't require that you support all VT420 functionality.