Implementation of scrollback #657

neon64 · Jul 12, 2017

The Grid<T> is now a view into a region (I called it the 'active region') of a VecDeque. 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 a Vec, 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':

configurable max scrollback length
write new tests
fix existing ref tests
measure performance impact (it seems fine but some numbers would be more reassuring)
fix out of bounds errors on resize

tbodt · Jul 12, 2017

tbodt reviewed Jul 12, 2017

View changes

wut

Oh lol. That's obviously a typo

I've fixed it in ac283f9

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.

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 dmesg in alacritty to get lots of output, and then full-screen and un-full-screen the window, alacritty crashes at the un-full-screen step with this stack trace:

$ env RUST_BACKTRACE=1 target/release/alacritty-scroll
Resizing Line(10) Column(101)
Resizing Line(10) Column(101)
Resizing Line(68) Column(177)
Resizing Line(68) Column(177)
Resizing Line(70) Column(177)
Resizing Line(70) Column(177)
Resizing Line(68) Column(177)
Resizing Line(68) Column(177)
thread 'main' panicked at 'Out of bounds access', /checkout/src/libcore/option.rs:794
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:71
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   2: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:371
             at /checkout/src/libstd/panicking.rs:549
   3: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   4: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:495
   5: core::panicking::panic_fmt
             at /checkout/src/libstd/panicking.rs:471
   6: core::option::expect_failed
             at /checkout/src/libcore/option.rs:794
   7: alacritty::run
             at /checkout/src/libcore/option.rs:297
   8: alacritty::main
             at ./src/main.rs:45
   9: main
  10: __libc_start_main
  11: _start

This does not happen on alacritty master commit 94849c4, so I suspect this PR introduces this crash.

nh2 · Jul 19, 2017

When I use this branch in i3 (alone on a workspace), run dmesg in alacritty to get lots of output, and then full-screen and un-full-screen the window, alacritty crashes at the un-full-screen step with this stack trace:

$ env RUST_BACKTRACE=1 target/release/alacritty-scroll
Resizing Line(10) Column(101)
Resizing Line(10) Column(101)
Resizing Line(68) Column(177)
Resizing Line(68) Column(177)
Resizing Line(70) Column(177)
Resizing Line(70) Column(177)
Resizing Line(68) Column(177)
Resizing Line(68) Column(177)
thread 'main' panicked at 'Out of bounds access', /checkout/src/libcore/option.rs:794
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:71
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   2: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:371
             at /checkout/src/libstd/panicking.rs:549
   3: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   4: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:495
   5: core::panicking::panic_fmt
             at /checkout/src/libstd/panicking.rs:471
   6: core::option::expect_failed
             at /checkout/src/libcore/option.rs:794
   7: alacritty::run
             at /checkout/src/libcore/option.rs:297
   8: alacritty::main
             at ./src/main.rs:45
   9: main
  10: __libc_start_main
  11: _start

This does not happen on alacritty master commit 94849c4, so I suspect this PR introduces this crash.

actually works well on macOS

monouser7dig · Jul 19, 2017

actually works well on macOS

Tested it out for a bit on Linux (X not wayland). It is working incredibly well!

ianks · Jul 20, 2017

Tested it out for a bit on Linux (X not wayland). It is working incredibly well!

Thanks @nh2 and @qxzw for the reports. I'm aware that resizing at the moment is really buggy on my fork - I have some improvements underway right now however it could be slow progress (for me it is during the school term time so I don't have much free time).

neon64 · Jul 21, 2017

Thanks @nh2 and @qxzw for the reports. I'm aware that resizing at the moment is really buggy on my fork - I have some improvements underway right now however it could be slow progress (for me it is during the school term time so I don't have much free time).

@neon64 -- did you want to hand off this PR to another contributor?

brycefisher · Jul 27, 2017

@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.

neon64 · Jul 28, 2017

@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.

@neon64

I can confirm the pushed commit 1be37ff fixes the crashing problem.

But the commit on top 92a9d9b9 - Merged changes from upstream breaks scrolling (it simply doesn't scroll).

nh2 · Jul 28, 2017

@neon64

I can confirm the pushed commit 1be37ff fixes the crashing problem.

But the commit on top 92a9d9b9 - Merged changes from upstream breaks scrolling (it simply doesn't scroll).

@neon64 this might be easier to maintain if you could rebase instead of merging master.

jwilm · Jul 28, 2017

@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

neon64 · Jul 28, 2017

@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 tput -S or cat, and then resize the window, I get lots of visual glitches. I've tracked this down to the window not being redrawn on resize (usually it is because the shell prints a new prompt), however if I add self.dirty=true; inside Term::resize it doesn't help. I think this is because resizing is separate from the normal event loop, or at least doesn't follow the usual input->update->render cycle like eg: key input. I'm afraid I'm really unfamiliar with this part of the internals so any help would be appreciated.

neon64 · Jul 29, 2017

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 tput -S or cat, and then resize the window, I get lots of visual glitches. I've tracked this down to the window not being redrawn on resize (usually it is because the shell prints a new prompt), however if I add self.dirty=true; inside Term::resize it doesn't help. I think this is because resizing is separate from the normal event loop, or at least doesn't follow the usual input->update->render cycle like eg: key input. I'm afraid I'm really unfamiliar with this part of the internals so any help would be appreciated.

I hope I've rebased it correctly - it was a bit messy because I had to rewind the merge as well

@neon64 There seems to be somethin in the recent master that breaks the scrolling feature when scrolling with the ThinkPad "middle" button (which is my main way of scrolling).

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 1be37ff.

So currently commit 1be37ff is the only one where I can scroll with both mouse and ThinkPad middle button, and it doesn't crash when using fullscreening.

nh2 · Jul 29, 2017

I hope I've rebased it correctly - it was a bit messy because I had to rewind the merge as well

@neon64 There seems to be somethin in the recent master that breaks the scrolling feature when scrolling with the ThinkPad "middle" button (which is my main way of scrolling).

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 1be37ff.

So currently commit 1be37ff is the only one where I can scroll with both mouse and ThinkPad middle button, and it doesn't crash when using fullscreening.

@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 println!s inside of this function to see what's happening. Which platform are you testing this on?

neon64 · Jul 30, 2017

@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 println!s inside of this function to see what's happening. Which platform are you testing this on?

@neon64 Platform is Ubuntu 16.04.

Yes, I can confirm that on the working branch, on_mouse_wheel fires for both real mouse wheel and Thinkpad button. On the later broken branch, it no longer fires for the Thinkpad button.

nh2 · Jul 30, 2017

@neon64 Platform is Ubuntu 16.04.

Yes, I can confirm that on the working branch, on_mouse_wheel fires for both real mouse wheel and Thinkpad button. On the later broken branch, it no longer fires for the Thinkpad button.

Looks like you are right: A quick bisect shows that the problem is introduced in this commit:

8e7dd00 Update to latest Glutin/winit (#671)

nh2 · Jul 30, 2017

Looks like you are right: A quick bisect shows that the problem is introduced in this commit:

8e7dd00 Update to latest Glutin/winit (#671)

I'm not sure how to continue debugging -- neither winit nor glutin seem to have have hangelog files that describe what changed between the releases.

@tomaka Do you have an idea what might have broken scroll support of the Thinkpad middle mouse button?

nh2 · Jul 30, 2017

I'm not sure how to continue debugging -- neither winit nor glutin seem to have have hangelog files that describe what changed between the releases.

@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 · Jul 30, 2017

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?

nh2 · Jul 30, 2017

@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 target/debug/examples/window:

On glutin 0.6.1 (glutin commit e18ff88d) I get the output

MouseWheel(LineDelta(0, 1), Moved)
MouseWheel(LineDelta(0, 1), Moved)
MouseWheel(LineDelta(0, 1), Moved)
MouseWheel(LineDelta(0, 1), Moved)
MouseWheel(LineDelta(0, -1), Moved)
MouseWheel(LineDelta(0, -1), Moved)

while on current glutin master 9625c81c3 I get the output:

WindowEvent { window_id: WindowId(X(WindowId(81788931))), event: MouseWheel { device_id: DeviceId(X(DeviceId(2))), delta: LineDelta(0, -1), phase: Moved } }
DeviceEvent { device_id: DeviceId(X(DeviceId(13))), event: Button { button: ButtonId(5), state: Pressed } }
DeviceEvent { device_id: DeviceId(X(DeviceId(13))), event: Button { button: ButtonId(5), state: Released } }

If on current master I use a real mouse wheel I get

WindowEvent { window_id: WindowId(X(WindowId(81788931))), event: MouseWheel { device_id: DeviceId(X(DeviceId(2))), delta: LineDelta(0, 1), phase: Moved } }
DeviceEvent { device_id: DeviceId(X(DeviceId(11))), event: Motion { axis: AxisId(2), value: 1 } }
WindowEvent { window_id: WindowId(X(WindowId(81788931))), event: MouseWheel { device_id: DeviceId(X(DeviceId(2))), delta: LineDelta(0, -1), phase: Moved } }
DeviceEvent { device_id: DeviceId(X(DeviceId(11))), event: Motion { axis: AxisId(2), value: 1 } }

Not sure yet if that provides any insight?

nh2 · Jul 30, 2017

@tomaka Well so the first thing I notice is that with glutin's target/debug/examples/window:

On glutin 0.6.1 (glutin commit e18ff88d) I get the output

MouseWheel(LineDelta(0, 1), Moved)
MouseWheel(LineDelta(0, 1), Moved)
MouseWheel(LineDelta(0, 1), Moved)
MouseWheel(LineDelta(0, 1), Moved)
MouseWheel(LineDelta(0, -1), Moved)
MouseWheel(LineDelta(0, -1), Moved)

while on current glutin master 9625c81c3 I get the output:

WindowEvent { window_id: WindowId(X(WindowId(81788931))), event: MouseWheel { device_id: DeviceId(X(DeviceId(2))), delta: LineDelta(0, -1), phase: Moved } }
DeviceEvent { device_id: DeviceId(X(DeviceId(13))), event: Button { button: ButtonId(5), state: Pressed } }
DeviceEvent { device_id: DeviceId(X(DeviceId(13))), event: Button { button: ButtonId(5), state: Released } }

If on current master I use a real mouse wheel I get

WindowEvent { window_id: WindowId(X(WindowId(81788931))), event: MouseWheel { device_id: DeviceId(X(DeviceId(2))), delta: LineDelta(0, 1), phase: Moved } }
DeviceEvent { device_id: DeviceId(X(DeviceId(11))), event: Motion { axis: AxisId(2), value: 1 } }
WindowEvent { window_id: WindowId(X(WindowId(81788931))), event: MouseWheel { device_id: DeviceId(X(DeviceId(2))), delta: LineDelta(0, -1), phase: Moved } }
DeviceEvent { device_id: DeviceId(X(DeviceId(11))), event: Motion { axis: AxisId(2), value: 1 } }

Not sure yet if that provides any insight?

With some more bisecting I found that the change in winit from

WindowEvent { window_id: WindowId(X(WindowId(139764517513424))), event: MouseWheel(LineDelta(0, -1), Moved) }
WindowEvent { window_id: WindowId(X(WindowId(139764517513424))), event: MouseWheel(LineDelta(0, 1), Moved) }

WindowEvent { window_id: WindowId(X(WindowId(81788929))), event: MouseInput { device_id: DeviceId(X(DeviceId(2))), state: Released, button: Other(4) } }
DeviceEvent { device_id: DeviceId(X(DeviceId(13))), event: Button { button: ButtonId(4), state: Pressed } }
DeviceEvent { device_id: DeviceId(X(DeviceId(13))), event: Button { button: ButtonId(4), state: Released } }

is in commit 22bc119c... Richer input events

nh2 · Jul 30, 2017

With some more bisecting I found that the change in winit from

WindowEvent { window_id: WindowId(X(WindowId(139764517513424))), event: MouseWheel(LineDelta(0, -1), Moved) }
WindowEvent { window_id: WindowId(X(WindowId(139764517513424))), event: MouseWheel(LineDelta(0, 1), Moved) }

WindowEvent { window_id: WindowId(X(WindowId(81788929))), event: MouseInput { device_id: DeviceId(X(DeviceId(2))), state: Released, button: Other(4) } }
DeviceEvent { device_id: DeviceId(X(DeviceId(13))), event: Button { button: ButtonId(4), state: Pressed } }
DeviceEvent { device_id: DeviceId(X(DeviceId(13))), event: Button { button: ButtonId(4), state: Released } }

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?

nh2 · Jul 30, 2017

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 Button4/Button5 to MouseWheel events:

tomaka/winit@22bc119#diff-2e05a82bc4ad5f1e53602d126bbe42acL218-L227

nh2 · Jul 30, 2017

@tomaka @Ralith I suspect it might be this change that removed the translation of Button4/Button5 to MouseWheel events:

tomaka/winit@22bc119#diff-2e05a82bc4ad5f1e53602d126bbe42acL218-L227

@neon64 OK, here's a commit on top of your branch that fixes scrolling with middle mouse button + TrackPoint: nh2/alacritty@be4c141

@tomaka @Ralith What we still need to know from you guys is whether the removal of translate_event() that translated Button4/Button5 events to MouseWheel events was intentional or not, to decide whether it should be handled in Alacritty (and all other apps that use glutin/winit) or reintroduced in winit.

Do you have opinions on this?

nh2 · Jul 30, 2017

@neon64 OK, here's a commit on top of your branch that fixes scrolling with middle mouse button + TrackPoint: nh2/alacritty@be4c141

@tomaka @Ralith What we still need to know from you guys is whether the removal of translate_event() that translated Button4/Button5 events to MouseWheel events was intentional or not, to decide whether it should be handled in Alacritty (and all other apps that use glutin/winit) or reintroduced in winit.

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.

tomaka · Jul 30, 2017

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 2~ into the prompt.

Some relevant section in alacrity.yml: - { key: PageUp, mods: Shift, chars: "\x1b[5;2~" }

Other terminals (e.g. gnome-terminal) handle that this way:

If they are in "normal" mode, then the mentioned key combinations scroll them.
If they run something that takes control of rendering, such as screen, then they forward the \x1b[5;2~.

Does Alacritty currently know whether an application like screen is running that uses that "takes control of the terminal" mode (I don't remember what that is called properly)?

nh2 · Jul 30, 2017

Another question @neon64:

Should Shift + PageUp/PageDown be correctly scrolling up and down currently?

For me it doesn't, only inserts 2~ into the prompt.

Some relevant section in alacrity.yml: - { key: PageUp, mods: Shift, chars: "\x1b[5;2~" }

Other terminals (e.g. gnome-terminal) handle that this way:

If they are in "normal" mode, then the mentioned key combinations scroll them.
If they run something that takes control of rendering, such as screen, then they forward the \x1b[5;2~.

Does Alacritty currently know whether an application like screen is running that uses that "takes control of the terminal" mode (I don't remember what that is called properly)?

CC @Ralith (who authored that change) -- do you know if the change may have broken ThinkPad middle mouse button scrolling?

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 tomaka/winit#248.

Ralith · Jul 30, 2017

CC @Ralith (who authored that change) -- do you know if the change may have broken ThinkPad middle mouse button scrolling?

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 tomaka/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.

tbodt · Jul 30, 2017

@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 ScrollUp and ScrollDown actions which you can bind to any key you want, and yes, it seems like this would be something good to have in the default config if it is expected behaviour from other terminals... Would you desire PageUp and PageDown actions as well? (because I imagine those could be easily implemented as needed)

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.

neon64 · Jul 31, 2017

@nh2 As part of my initial commit, I added ScrollUp and ScrollDown actions which you can bind to any key you want, and yes, it seems like this would be something good to have in the default config if it is expected behaviour from other terminals... Would you desire PageUp and PageDown actions as well? (because I imagine those could be easily implemented as needed)

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.

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.

@tbodt Right, that makes sense to me, I'm just wondering if Alacritty should also make a distinction / allow to configure different actions between that raw mode and "normal" mode, like other terminals do.

Would you desire PageUp and PageDown actions as well?

@neon64 I think so -- at least I use them all the time in both UI terminals and the Linux virtual terminals.

These keybindings are common:

Ctrl+Shift+Up/Down - scrolls a single line, that's ScrollUp / ScrollDown that you've already implemented.
Shift+PgUp/PgDown - scrolls an entire page, that's the PageUp / PageDown that you suggest
Shift+Home/End - scrolls to the top/bottom

nh2 · Jul 31, 2017

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.

@tbodt Right, that makes sense to me, I'm just wondering if Alacritty should also make a distinction / allow to configure different actions between that raw mode and "normal" mode, like other terminals do.

Would you desire PageUp and PageDown actions as well?

@neon64 I think so -- at least I use them all the time in both UI terminals and the Linux virtual terminals.

These keybindings are common:

Ctrl+Shift+Up/Down - scrolls a single line, that's ScrollUp / ScrollDown that you've already implemented.
Shift+PgUp/PgDown - scrolls an entire page, that's the PageUp / PageDown that you suggest
Shift+Home/End - scrolls to the top/bottom

I'd propose to table the additional feature request for scroll up / down key mappings for a future PR. It seems like there's plenty of work and changes already happening here in this PR, and adding that feature will be much easier to tackle once scrollback lands.

Additionally, it looks like the bug discussed above has been merged: tomaka/winit#248. Perhaps we could pull in the fix and rebase against master of this project?

brycefisher · Aug 16, 2017

I'd propose to table the additional feature request for scroll up / down key mappings for a future PR. It seems like there's plenty of work and changes already happening here in this PR, and adding that feature will be much easier to tackle once scrollback lands.

Additionally, it looks like the bug discussed above has been merged: tomaka/winit#248. Perhaps we could pull in the fix and rebase against master of this project?

@brycefisher implementing those extra keybindings is like 10 more lines of code - I think I've already implemented half of it on my local machine anyway.

Regarding the rebase, I'll get on to it when I get back to a proper computer.

neon64 · Aug 17, 2017

@brycefisher implementing those extra keybindings is like 10 more lines of code - I think I've already implemented half of it on my local machine anyway.

Regarding the rebase, I'll get on to it when I get back to a proper computer.

Just downloaded and installed this branch, seems to be working great. Awesome work. Looking forward to the release.

nixpulvis · Aug 27, 2017

Just downloaded and installed this branch, seems to be working great. Awesome work. Looking forward to the release.

Sorry everybody for going afk for what seems like ages. I've finally rebased on top of the latest changes and also added those key commands. Regarding the next steps to actually get this merged, the main thing afaik is fixing tests.. If anyone can help with that it would be much appreciated, as alone I'll probably be beaten by a snail.

neon64 · Aug 29, 2017

Sorry everybody for going afk for what seems like ages. I've finally rebased on top of the latest changes and also added those key commands. Regarding the next steps to actually get this merged, the main thing afaik is fixing tests.. If anyone can help with that it would be much appreciated, as alone I'll probably be beaten by a snail.

tshakah · Aug 29, 2017

tshakah reviewed Aug 29, 2017

View changes

Merge conflict :(

(Just pulled and tried to build locally to test)

Merge conflict :(

(Just pulled and tried to build locally to test)

(Thanks for all your work on this though! It's a feature I've been wanting)

Oh whoops yes I realised that right away but forgot to push the fix.. done now

Thanks. Out of interest (not too hot on github flow) - if wanted to fix it would the correct thing be to fork off of your branch and open another pull request?

@tshakah Yes - to be clear though the PR should be opened against neon64's (forked) repo, not this one. That way you can get your changes merged into this branch, and they'll show up here in the 'main' repo automatically; otherwise you'd essentially replace this PR by including all neon64's commits and adding to them. 🙂

@neon64 thanks for your continued work on this feature. No rush on getting tests fixed up, it'll probably be some days before I get a chance to review what's here anyway. Thanks for your patience!

jwilm · Aug 29, 2017

@neon64 thanks for your continued work on this feature. No rush on getting tests fixed up, it'll probably be some days before I get a chance to review what's here anyway. Thanks for your patience!

I fixed most of the tests: neon64/alacritty#2

tbodt · Aug 29, 2017

I fixed most of the tests: neon64/alacritty#2

I've gone ahead and implemented configurable maximum scrollback lines. I'm not sure how best to organise the new data types. I actually created 3 new ones:

one that directly mirrors the yaml code, in mod config
a 'nicer' enum that conveys the two possibilities (Disabled and MaxLines) and finally
a state struct internal to mod grid that sort of 'caches' the max_lines and so (theoretically) will be more optimal tthan matching on an enum every time. (however that said in practice there is so much indirection and branching inside functions like insert_new_lines that this is probably just premature optimisation).

Currently, when scrollback is disabled, it tries its best to emulate og behaviour before this PR, however at the moment it 'breaks' (just scrolls a little bit - at least it doesn't crash) if you resize the window. If anyone thinks that a 'disabled' mode isn't actually required, then let me know.

neon64 · Sep 2, 2017

I've gone ahead and implemented configurable maximum scrollback lines. I'm not sure how best to organise the new data types. I actually created 3 new ones:

one that directly mirrors the yaml code, in mod config
a 'nicer' enum that conveys the two possibilities (Disabled and MaxLines) and finally
a state struct internal to mod grid that sort of 'caches' the max_lines and so (theoretically) will be more optimal tthan matching on an enum every time. (however that said in practice there is so much indirection and branching inside functions like insert_new_lines that this is probably just premature optimisation).

Currently, when scrollback is disabled, it tries its best to emulate og behaviour before this PR, however at the moment it 'breaks' (just scrolls a little bit - at least it doesn't crash) if you resize the window. If anyone thinks that a 'disabled' mode isn't actually required, then let me know.

I'm not sure if this should be part of this pull request, but currently it is not possible to select text while scrolling - if you select the line, start the selection and then scroll up while holding the mouse cursor the selection will not change/expand.

Eyenseo · Sep 2, 2017

I'm not sure if this should be part of this pull request, but currently it is not possible to select text while scrolling - if you select the line, start the selection and then scroll up while holding the mouse cursor the selection will not change/expand.

@neon64 I've fixed the failing ref tests and sent a PR.

This fixes the crashes when growing the buffer, however the issue with the last line appearing multiple times is still present. When growing a buffer instead of the scrollback history filling the screen, it just repeats the last line (prompt) over and over again.

chrisduerr · Dec 20, 2017

@neon64 I've fixed the failing ref tests and sent a PR.

This fixes the crashes when growing the buffer, however the issue with the last line appearing multiple times is still present. When growing a buffer instead of the scrollback history filling the screen, it just repeats the last line (prompt) over and over again.

@chrisduerr Okay, thanks for the PR! but that's weird because I'm not experiencing any visual glitches. Could you send a screenshot or something? I'm not entirely sure what you're talking about

neon64 · Dec 21, 2017

@chrisduerr Okay, thanks for the PR! but that's weird because I'm not experiencing any visual glitches. Could you send a screenshot or something? I'm not entirely sure what you're talking about

@neon64 I made a short video:
https://u.teknik.io/FQtPu.webm

chrisduerr · Dec 21, 2017

@neon64 I made a short video:
https://u.teknik.io/FQtPu.webm

Oh right, that's very strange - not something I'm experiencing. What platform/shell are you using? I know bash and fish on Mac work for me. I'll try the same on Linux soon

neon64 · Dec 21, 2017

Oh right, that's very strange - not something I'm experiencing. What platform/shell are you using? I know bash and fish on Mac work for me. I'll try the same on Linux soon

I'm using zsh on linux/X11/i3(-gaps). I can also check if this happens in a macos VM on my laptop.

chrisduerr · Dec 21, 2017

I'm using zsh on linux/X11/i3(-gaps). I can also check if this happens in a macos VM on my laptop.

@chrisduerr I can reproduce this bug with termite and xterm too. https://vimeo.com/248297388
The difference between these three is that alacritty will duplicate also the "second" line while the other terminals will only duplicate the "first", further xterm will only start to duplicate if the line was wrapped / too long.

Arch/X11/zsh/i3

Eyenseo · Dec 21, 2017

@chrisduerr I can reproduce this bug with termite and xterm too. https://vimeo.com/248297388
The difference between these three is that alacritty will duplicate also the "second" line while the other terminals will only duplicate the "first", further xterm will only start to duplicate if the line was wrapped / too long.

Arch/X11/zsh/i3

Other than running existing, and limited bench tests, what can/should be done to ensure this PR's performance is acceptable?

nixpulvis · Dec 21, 2017

Other than running existing, and limited bench tests, what can/should be done to ensure this PR's performance is acceptable?

Regarding perf, I've just published the start to a benchmarking tool, vtebench. It currently can generate a benchmark that is testing vim-like applications (random cursor position updates and text output). There are issues for a couple of the other tests I would like to add. There's also work to do on automating some of these tests and generating statistics.

jwilm · Dec 25, 2017

Regarding perf, I've just published the start to a benchmarking tool, vtebench. It currently can generate a benchmark that is testing vim-like applications (random cursor position updates and text output). There are issues for a couple of the other tests I would like to add. There's also work to do on automating some of these tests and generating statistics.

I've compared the current master to this PR with the new benchmarking tool @jwilm wrote, here are the results:

Alt Screen Random Write	First Run	Second Run	Third Run
Master	0.950	0.933	0.918
PR	0.983	0.988	0.978

This test doesn't really do much related to scrolling as far as I know, so as expected, the results are pretty much even.

Scrolling	First Run	Second Run	Third Run
Master	1.512	1.633	1.582
PR	1.070	1.166	1.110

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.

Scrolling In Region	First Run	Second Run	Third Run
Master	1.399	1.409	1.360
PR	2.108	2.070	2.105

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 vtebench but made a change so the scrolling benchmarks would run in the primary screen buffer, except for this everything is unchanged.

chrisduerr · Dec 27, 2017

I've compared the current master to this PR with the new benchmarking tool @jwilm wrote, here are the results:

Alt Screen Random Write	First Run	Second Run	Third Run
Master	0.950	0.933	0.918
PR	0.983	0.988	0.978

This test doesn't really do much related to scrolling as far as I know, so as expected, the results are pretty much even.

Scrolling	First Run	Second Run	Third Run
Master	1.512	1.633	1.582
PR	1.070	1.166	1.110

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.

Scrolling In Region	First Run	Second Run	Third Run
Master	1.399	1.409	1.360
PR	2.108	2.070	2.105

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 vtebench but made a change so the scrolling benchmarks would run in the primary screen buffer, except for this everything is unchanged.

FichteFoll · Dec 28, 2017

FichteFoll reviewed Dec 28, 2017

View changes

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).

FichteFoll · Dec 28, 2017

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 faux scrolling and not part of this PR yet. On neon's github there is currently an open PR about rebasing on top of master, which will add the faux scrolling feature to this PR. But it still needs some tweaks before it can be merged.

chrisduerr · Dec 28, 2017

Scrolling in the alternate buffer is called faux scrolling and not part of this PR yet. On neon's github there is currently an open PR about rebasing on top of master, which will add the faux scrolling feature to this PR. But it still needs some tweaks before it can be merged.

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 · Jan 5, 2018

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.

chrisduerr · Jan 5, 2018

@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.

ianks · Jan 6, 2018

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.

Kommynct · Jan 7, 2018

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.
(When working with a tiling WM, windows are resized frequently and losing the previously printed text is not so nice.)

FichteFoll · Jan 7, 2018

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.
(When working with a tiling WM, windows are resized frequently and losing the previously printed text is not so nice.)

Reflow will be implemented separately, subscribe to #591. I think tmux could also handle reflows even if alacritty doesn't natively support this (I'm not sure thought), but current implementation of scrollback doesn't play well with tmux anyway - this is tracked by #1000.

maximbaz · Jan 7, 2018

Reflow will be implemented separately, subscribe to #591. I think tmux could also handle reflows even if alacritty doesn't natively support this (I'm not sure thought), but current implementation of scrollback doesn't play well with tmux anyway - this is tracked by #1000.

@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?

nixpulvis · Jan 11, 2018

@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.

FichteFoll · Jan 11, 2018

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?

FichteFoll · Jan 11, 2018

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?

@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?

As a separate PR, not to delay this one any longer.

maximbaz · Jan 11, 2018

@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?

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:

# Generate a little output
echo '0\n1\n2\n3\n4\n5\n6\n7\n8\n9'
vim -c q # Open and close vim
# Observe some of echo's output missing

And fragments of a man page can be captured in the scrollback buffer:

man man
# [enter 'dq' into man]
# [scroll up to see part of man page]

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".

[The scrollback buffer] contains all the text that has been displayed on the screen, including both standard output and standard error from every program you run in the terminal.
...
Unlike the ordinary buffer that's used for most terminal interaction with sequential output, the alternate screen buffer is just the exact size of your terminal. There's no scrolling up or down in it because it's no bigger than what's displayed.
The idea there is to allow a full-screen application to do what it needs to do without being interfered with by anything you already had on the screen, and then to let you go back to exactly the display you had before.

So, I'm guessing that alternative implementation would avoid these issues?

alexozer · Jan 11, 2018

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:

# Generate a little output
echo '0\n1\n2\n3\n4\n5\n6\n7\n8\n9'
vim -c q # Open and close vim
# Observe some of echo's output missing

And fragments of a man page can be captured in the scrollback buffer:

man man
# [enter 'dq' into man]
# [scroll up to see part of man page]

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".

[The scrollback buffer] contains all the text that has been displayed on the screen, including both standard output and standard error from every program you run in the terminal.
...
Unlike the ordinary buffer that's used for most terminal interaction with sequential output, the alternate screen buffer is just the exact size of your terminal. There's no scrolling up or down in it because it's no bigger than what's displayed.
The idea there is to allow a full-screen application to do what it needs to do without being interfered with by anything you already had on the screen, and then to let you go back to exactly the display you had before.

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.

maximbaz · Jan 11, 2018

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?

atopia · Jan 11, 2018

@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?

@atopia Ah I think you're right, I was setting TERM to something else manually in zshrc which now appears to produce the behavior I was seeing. I'll retract my comment.

@maximbaz you might want to update your issue because it might truly only affect tmux.

alexozer · Jan 11, 2018

@atopia Ah I think you're right, I was setting TERM to something else manually in zshrc which now appears to produce the behavior I was seeing. I'll retract my comment.

@maximbaz you might want to update your issue because it might truly only affect tmux.

Have the testcases that needs to be written been specified? Seems hard to pitch in without any specifications.

Klemetz · Jan 15, 2018

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?

NellyWhadsDev · Jan 30, 2018

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.

FichteFoll · Jan 30, 2018

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?
Are you exploring an alternative approach, as was mentioned above?
Is this just blocked on rebasing, thorough testing and bug fixing?
Will this ever be merged?

theduke · Mar 2, 2018

@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?
Are you exploring an alternative approach, as was mentioned above?
Is this just blocked on rebasing, thorough testing and bug fixing?
Will this ever be merged?

Just for the record I've got an open pull request to @neon64 rebasing this to master neon64#10.

chetgurevitch · Mar 2, 2018

Just for the record I've got an open pull request to @neon64 rebasing this to master neon64#10.

See #1147 for the alternative scrollback implementation.

chrisduerr · Mar 9, 2018

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 ❤️

valignatev · Mar 19, 2018

@chetgurevitch Compiled your rebased PR on Arch without any problem and using it for about 2 weeks without any issue. Much love ❤️

gibfahn referenced this pull request Aug 12, 2017
Open
[Feature Request] Support marks (or scroll to last command) #725

Merge branch 'scrollback' of github.com:chrisduerr/alacritty into scr…
…ollback

The key that signed this is expired.

GPG key ID: 85CDAE3C164BA7B4 Learn about signing commits

e27ee58

Merge pull request #9 from chrisduerr/scrollback
Fix failing ref tests

This commit was created on GitHub.com and signed with a verified signature using GitHub’s key.

GPG key ID: 4AEE18F83AFDEB23 Learn about signing commits

a0b55ca

nixpulvis referenced this pull request Dec 21, 2017
Merged
Implement faux scrolling #946

maximbaz referenced this pull request Jan 6, 2018
Open
Make scrollback support alternative screen buffer (e.g. tmux history) #1000

FichteFoll referenced this pull request Jan 30, 2018
Open
Ranger image preview not working correctly #1021

jwilm referenced this pull request Mar 9, 2018
Open
Scrollback #1147

maximbaz referenced this pull request Mar 9, 2018
Closed
Scroll multiplier should be configurable #1160

                  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.

@@ -1055,6 +1042,7 @@ impl Term {
                  self.tabs = IndexRange::from(Column(0)..self.grid.num_cols())
                      .map(|i| (*i as usize) % TAB_SPACES == 0)
                      .collect::<Vec<bool>>();
+        +<<<<<<< HEAD

            - { 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~"                   }

Please note that GitHub no longer supports your web browser.

jwilm/alacritty

Join GitHub today

Implementation of scrollback #657

Conversation

neon64 commented Jul 12, 2017 • edited Edited 2 times neon64 Dec 15, 2017 neon64 Jul 12, 2017

tbodt reviewed Jul 12, 2017 View changes

This comment has been minimized.

tbodt Jul 12, 2017

This comment has been minimized.

neon64 Jul 12, 2017

This comment has been minimized.

neon64 Jul 15, 2017

This comment has been minimized.

OJFord Jul 15, 2017

This comment has been minimized.

nh2 Jul 19, 2017

nh2 commented Jul 19, 2017

This comment has been minimized.

monouser7dig Jul 19, 2017

monouser7dig commented Jul 19, 2017

This comment has been minimized.

ianks Jul 20, 2017

ianks commented Jul 20, 2017

This comment has been minimized.

neon64 Jul 21, 2017

neon64 commented Jul 21, 2017

This comment has been minimized.

brycefisher Jul 27, 2017

brycefisher commented Jul 27, 2017

This comment has been minimized.

neon64 Jul 28, 2017

neon64 commented Jul 28, 2017

This comment has been minimized.

nh2 Jul 28, 2017

nh2 commented Jul 28, 2017 • edited Edited 1 time nh2 Jul 28, 2017

This comment has been minimized.

jwilm Jul 28, 2017

jwilm commented Jul 28, 2017

This comment has been minimized.

neon64 Jul 28, 2017

neon64 commented Jul 28, 2017 • edited Edited 1 time neon64 Jul 28, 2017

This comment has been minimized.

neon64 Jul 29, 2017

neon64 commented Jul 29, 2017

This comment has been minimized.

nh2 Jul 29, 2017

nh2 commented Jul 29, 2017

This comment has been minimized.

neon64 Jul 30, 2017

neon64 commented Jul 30, 2017

This comment has been minimized.

nh2 Jul 30, 2017

nh2 commented Jul 30, 2017

This comment has been minimized.

nh2 Jul 30, 2017

nh2 commented Jul 30, 2017 • edited Edited 1 time nh2 Jul 30, 2017

This comment has been minimized.

nh2 Jul 30, 2017

nh2 commented Jul 30, 2017

This comment has been minimized.

tomaka Jul 30, 2017

tomaka commented Jul 30, 2017

This comment has been minimized.

nh2 Jul 30, 2017

nh2 commented Jul 30, 2017

This comment has been minimized.

nh2 Jul 30, 2017

nh2 commented Jul 30, 2017 • edited Edited 1 time nh2 Jul 30, 2017

This comment has been minimized.

nh2 Jul 30, 2017

nh2 commented Jul 30, 2017

This comment has been minimized.

nh2 Jul 30, 2017

nh2 commented Jul 30, 2017

This comment has been minimized.

nh2 Jul 30, 2017

nh2 commented Jul 30, 2017

nh2 added a commit to nh2/alacritty that referenced this pull request Jul 30, 2017

This comment has been minimized.

neon64 commented Jul 12, 2017 •

Edited 2 times

neon64
Dec 15, 2017

neon64
Jul 12, 2017

tbodt reviewed Jul 12, 2017

View changes

nh2 commented Jul 28, 2017 •

Edited 1 time

nh2
Jul 28, 2017

neon64 commented Jul 28, 2017 •

Edited 1 time

neon64
Jul 28, 2017

nh2 commented Jul 30, 2017 •

Edited 1 time

nh2
Jul 30, 2017

nh2 commented Jul 30, 2017 •

Edited 1 time

nh2
Jul 30, 2017

nh2 commented Jul 30, 2017 •

Edited 1 time

nh2
Jul 30, 2017

tshakah reviewed Aug 29, 2017

View changes