Implementation of scrollback #657
Conversation
src/grid.rs
Outdated
|
|
||
| unsafe { | ||
| // check that src/dst are in bounds. Since index::Line newtypes usize, | ||
| // we can assume values are positive. | ||
| // we can implassume values are positive. |
There was a problem hiding this comment.
No, I think it should enter the vernacular:
implassume (verb)
(im·pluh·syoom)
- To assume such is the case; implement it if it turns out not to be.
|
When I use this branch in i3 (alone on a workspace), run This does not happen on alacritty master commit 94849c4, so I suspect this PR introduces this crash. |
|
actually works well on macOS |
|
Tested it out for a bit on Linux (X not wayland). It is working incredibly well! |
|
@neon64 -- did you want to hand off this PR to another contributor? |
|
@brycefisher I'm really sorry about the delays with this - I'm happy to keep driving the PR forward, but it may be at a slower pace than others would like, so in that way I think its a great idea if others want to contribute as well. |
|
I can confirm the pushed commit But the commit on top |
|
@neon64 this might be easier to maintain if you could rebase instead of merging master. |
|
@jwilm I hope I've rebased it correctly - it was a bit messy because I had to rewind the merge as well |
|
There's also a really subtle bug that I might need help diagnosing... If I run some command that just stays running with no output: eg |
@neon64 There seems to be somethin in the recent On your rebased commit c531d78 I cannot scroll with the middle button, same as in the case where you merged. But it worked for me on your original commit So currently commit |
|
@nh2 I'm 99% sure that's got nothing to do with my code, but rather something on the latest version of glutin/winit that means that the 'on scroll' callback never gets called (or with different values). Try adding some debugging |
|
@neon64 Platform is Ubuntu 16.04. Yes, I can confirm that on the working branch, |
|
I'm not sure how to continue debugging -- neither @tomaka Do you have an idea what might have broken scroll support of the Thinkpad middle mouse button? |
|
The glutin fork dated back from august 2016, so finding the commit that causes the problem might be hard. Winit and glutin shouldn't have had any change in their behaviour when it comes to scrolling, so it has to be a bug. |
|
@tomaka I'm new to glutin/winit and Rust in general, but I'd be happy to help with finding this problem. I see there are some examples in glutin/winit. Could I use any of them to bisect this? E.g. some example that simply prints scroll events? |
|
@tomaka Well so the first thing I notice is that with glutin's On while on current glutin master If on current master I use a real mouse wheel I get Not sure yet if that provides any insight? |
|
With some more bisecting I found that the change in is in commit 22bc119c... Richer input events |
|
CC @Ralith (who authored that change) -- do you know if the change may have broken ThinkPad middle mouse button scrolling? |
|
@tomaka @Ralith I suspect it might be this change that removed the translation of rust-windowing/winit@22bc119c#diff-2e05a82bc4ad5f1e53602d126bbe42acL218-L227 |
See alacritty#657 (comment) The glutin change rust-windowing/winit@22bc119c#diff-2e05a82bc4ad5f1e53602d126bbe42acL218-L227 removed the translation from mouse buttons 4 and 5 to MouseWheel events. As a result, we now have to handle them ourselves in Alacritty to make scrolling happen with those.
|
@neon64 OK, here's a commit on top of your branch that fixes scrolling with middle mouse button + TrackPoint: nh2@be4c141 @tomaka @Ralith What we still need to know from you guys is whether the removal of Do you have opinions on this? |
|
I guess it wasn't intentional. Since Button4 and 5 are mouse wheels, there's no point in reporting them as button presses anyway. But I'm waiting on Ralith's input. |
|
Another question @neon64: Should Shift + PageUp/PageDown be correctly scrolling up and down currently? For me it doesn't, only inserts Some relevant section in Other terminals (e.g.
Does Alacritty currently know whether an application like |
It looks like this is the case. When I wrote the change, I determined empirically that both touchpad and real mousewheel scrolling yielded motion events in addition to emulated clicks, and concluded that said motion events could therefore be relied upon. Under libinput, this is true even for trackpoints. Unfortunately, it appears that the specific case of wheel emulation used for the trackpoint scrolling under evdev does indeed fail to produce motion events, so winit should support this. Fix on the way at rust-windowing/winit#248. |
|
@nh2 If your alacritty.yml is configured to send ^[[5;2~ on shift+pageup, it's going to send ^[[5;2~ on shift+pageup, not scroll. |
|
@nh2 As part of my initial commit, I added I think you're referring to raw mode, although I'm not familiar enough with the rest of the codebase to know if/where Alacritty tracks that. |
|
I've compared the current master to this PR with the new benchmarking tool @jwilm wrote, here are the results:
This test doesn't really do much related to scrolling as far as I know, so as expected, the results are pretty much even.
This one has something to do with scrolling and as expected shows some more different results. I've checked this twice because I didn't expect the PR to be ahead here, but it definitely is ahead by more than just the margin of error and both runs have shown this.
This test showed the biggest difference between the two. I'm not quite sure why the gap is so massive here when the PR is ahead in the normal scrolling, but it falls behind significantly in this benchmark. I've also run this a couple of times and wasn't able to get under 2 seconds once with the PR. This was all tested on my Arch/X/i3/ZSH machine. I did not run the current master of |
| - { key: Home, chars: "\x1bOH", mode: AppCursor } | ||
| - { key: Home, chars: "\x1b[H", mode: ~AppCursor } | ||
| - { key: End, chars: "\x1bOF", mode: AppCursor } | ||
| - { key: End, chars: "\x1b[F", mode: ~AppCursor } | ||
| - { key: PageUp, mods: Shift, chars: "\x1b[5;2~" } | ||
| - { key: PageUp, mods: Control, chars: "\x1b[5;5~" } | ||
| #- { key: PageUp, mods: Control, chars: "\x1b[5;5~" } |
There was a problem hiding this comment.
I think you mean to comment out the Shift line, not the Control one.
|
I started using this as my main terminal now and so far it's been working nicely. The only thing I noticed is that scrolling with the scroll wheel is not supported while in the alternate buffer (i.e. when viewing a man page). |
|
Scrolling in the alternate buffer is called |
|
Just to understand, is there anything mandatory left to do here before this can be merged? It already works well and has been tried by many people (there is even a second AUR package created for alacritty, specifically based on this PR), and the change itself is huge making it difficult to review new additions. I've noted ideas to potentially add more tests and optimize "Scrolling in region" (as reported by @chrisduerr), can we do them in separate PRs? |
|
@maximbaz I've talked to @jwilm in IRC and he told me that he wants to investigate a different approach to scrollback and see if that might be a more beneficial implementation. So while this PR is in a good state right now, it will probably have to wait until @jwilm has some results on the different approach. |
|
IMO, scrollback is a necessary feature that far outweighs prospective perf gains. Merge it in, then optimize if needed. This PR is now 6 months old. A lot of people (including myself) won't use alacritty without this feature. |
|
I completely agree, it's already seemingly more performant than urxvt, I really want to replace termite with it as well. |
|
The only issue I still have is that lines are not re-wrapped when the window shrinks and are truncated instead. If you enlarge the window again, the truncated characters do not come back either, presumably because they are pruned from memory entirely. I don't know whether that is relevant to this PR in particular or "not a feature" of alacritty in general, but that's the only remaining thing from a usability standpoint. |
|
@maximbaz when you say separately do you mean using it's own buffer for the text? Or do you mean as a separate PR after this lands using the same facilities? |
|
Painting is based on a grid structure, which most likely is a strict two-dimensional array (or array-like). For reflow, painting needs to rebuild the grid and wrap source lines into potentially multiple grid lines. That's hat I think at least. In principle the implementation would be the same for current master and the scrollback PR, but the additional layer required to store the original line is kind of already there in the scrollback branch. |
|
Regarding this alternative implementation, do we have any information about that? Like, what would it do different compared to this one and what's the current state of that? |
As a separate PR, not to delay this one any longer. |
|
EDIT This comment can probably be ignored, I was setting an incorrect TERM in .zshrc to produce this. I don't mean to unnecessarily delay this any longer (or whether I should file this separately), but it seems like the current scrollback implementation does not play nicely (plays incorrectly?) with programs using the alternative screen buffer. For instance, opening and closing vim wipes some prior scrollback history: And fragments of a man page can be captured in the scrollback buffer: I'm guessing this stems from the fact that the current scrollback implementation buffers the display instead of stdout and stderror. However, this random person on the internet seems to suggest that stdout and stderr in other terminals solely occupies the scrollback buffer and that other display-filling programs like vim and man don't ever touch the scrollback buffer since they use the "alternative screen buffer".
So, I'm guessing that alternative implementation would avoid these issues? |
|
I was told on IRC that the alternative implementation will not cover this, so I made #1000 for this, but gave it a name specific to tmux only - I will rename now to better reflect the request. |
|
@alexozer I can't reproduce this here (Arch package alacritty-scrollback-git-0.1.0.754.ga0b55ca-1 on xorg 1.19.6-2 with Awesome). Not sure if that could cause it, but do you have the appropriate terminfo files? |
|
Have the testcases that needs to be written been specified? Seems hard to pitch in without any specifications. |
|
Is there a way I can start using this feature before it hits master? Should I just check out this branch and compile + follow regular install procedure? |
|
That's what I did, anyway. If you're on Arch, there is even a package for this branch on the AUR. |
|
@jwilm Considering the PR is approaching it's first birthday, I think some statement from you is needed here. What's the likely future of this branch? |
|
See #1147 for the alternative scrollback implementation. |
|
@chetgurevitch Compiled your rebased PR on Arch without any problem and using it for about 2 weeks without any issue. Much love ❤️ |
The
Grid<T>is now a view into a region (I called it the 'active region') of aVecDeque. When new lines are added, they are pushed onto the back of the queue, and once the scrollback buffer is considered 'full', then old lines are popped off the front of the queue. This seems to work rather well since, unlike aVec, elements don't need to be reshuffled around very often.Of course, as discussed in #124 there are a few things that need to be fixed before I'd consider this 'ready':
reftests