* #3686, #3082, #3321, #3493 are all good follow-ups here.Vim, Neovim, and MacVim can all exhibit slow scrolling in macOS. Methods have been updated to account for this. So, we can just leave itĪlone and when we come back to the main buffer, there it is. This makes other parts easier as well - weĭon't really need to do anything with the `_mutableViewport` in the altīuffer, because it's always in the same place. The Terminalĭoesn't need all that! All we need to do is have a separate `TextBuffer`įor the alt buffer contents. The Terminal's implementation is a little different than conhost's.Ĭonhost's implementation grew organically, so I had it straight upĬreate an entire new screen buffer for the alt buffer. Want to set the circled flag in VtRenderer when that happens just for a `Circling` methods was a great place to do this, but we don't actually
We need this so that when anĪpp requests the alt buffer in conpty, we can immediately flush theįrame before asking the Terminal side to switch to the other buffer. Very first thing this PR does: updates the
User scroll up to see the previous history (which it shouldn't). Currently, we just render the alt buffer state into the This PR allows the Terminal to actually use the alt bufferĪppropriately. But for now at least we're compatible with XTerm, and anyone that prefers it on by default can still trigger that manually. That said, I don't feel strongly about what this defaults too, and maybe there is a way to have it enabled by default and still work well with applications that handle the scrolling themselves. It seems like it's generating up/down key strokes as well as passing the mouse events through, so some of the time the cursor moves and some of the time the screen scrolls. I haven't tried Gnome Terminal, but Mintty definitely behaves weirdly for me with set mouse=a. when set mouse= they seem to send up/down key strokes, and when set mouse=a they seem to leave scroll handling to vim. And they both behave correctly whether set mouse= or set mouse=a.
#Iterm2 scroll windows
And note that this still only applies to conhost - it's not supported by Windows Terminal yet (that's why this issue is still open).Īre you sure about that? I just checked with Gnome Terminal (VTE based, I believe) and mintty. Yes, but only if you enable the alternate scrolling mode first (i.e. I'm no console guru, so I may have not totally understood the previous will your fix allow mouse scrolling within less? Also added a new unit test in `MouseInputTest` to confirm the correct sequences were generated for both `DECCKM` modes.Įr. Manually tested in VIM (although that required me enabling the _Alternate Scroll Mode_ myself first).
I've simply added a condition in the `TerminalInput::_SendAlternateScroll` method to send a different pair of sequences dependent on the state of `_cursorApplicationMode` flag. # Detailed Description of the Pull Request / Additional comments Issue number where discussion took place: #xxx If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. * I've discussed this with core contributors already. This PR updates the alternate scroll implementation to make sure the appropriate sequences are sent for both `DECCKM` modes.
However, the expected escape sequences for those keys are dependent on the state of the _Cursor Keys Mode_ ( `DECCKM`), but we haven't taken that into account. If the _Alternate Scroll Mode_ is enabled, the terminal generates up/down keystrokes when the mouse wheel is scrolled.
0 kommentar(er)
