alacritty: alacritty does not draw background color for (some) invisible characters

Thanks for the report! This should be relatively easy to fix as soon as I can make some time.

I’ve found a case with vim, that might be related to this or something completely different. Having default config for alacritty master and using vim with gruvbox dark theme I see black backgrounds when scrolling with j/k

@jwilm I think both are right after doing some research (or at least can be right). Its called background-color-erase, its something a terminal can support or not support via the bce setting. I don’t think alacritty ships and uses its own termcap file yet and is piggybacking off whatever TERM is set to. If TERM=xterm-256 color then bce is enabled . So when htop renders it thinks that erasing to the end of the line will have the currently set background color. We don’t see the problem in tmux or without tmux but TERM=tmux-256color, because it does not set bce in the terminfo. This results in htop not trying to draw line with erase to the end of the line.

neptune:~ $ infocmp xterm-256color | grep bce am, bce, ccc, km, mc5i, mir, msgr, npc, xenl, neptune:~ $

And for tmux-256 color

neptune:~ $ infocmp tmux-256color | grep bce neptune:~ $

So if the goal is be a xterm compatible / replacement then I think it should use the template, if not then ship a terminfo and use that (not setting bce). At some point the main documentation should be updated specifying what TERM= to use when using alacritty.

An empty cell is actually populated with ' ' and the default colour:

impl Default for Cell {
    fn default() -> Cell {
        Cell::new(
            ' ',
            Color::Named(NamedColor::Foreground),
            Color::Named(NamedColor::Background)
        )
    }
}

So the problem I guess is that white space characters (‘\n’, ‘\t’, …)don’t update the relevant cells with a colour update

Here is a gif of me moving around in vim a little bit and adding some text. Hopefully this helps to visualise the issue a little more.

I’m not too sure what invisible character (if any) vim tries to render when there is no text in a region, but maybe it might differentiate from the example given in the issue description?

Whoops - my bad! I didn’t realise I had to do that for each new terminal window.

Unfortunately this seems to have introduced a weird visual glitch and may have introduced a crash. Either that or made an existing crash more visible.

On the plus side it does seem to have fixed the case given by @d3rrial.

Issues: 1.) If I run @d3rrial’s example but then press ctrl+c to exit it the terminal crashes with this error:

thread 'pty reader' panicked at 'slice index starts at 80 but ends at 79', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/libcore/slice.rs:566
stack backtrace:
   1:        0x10e6dd3da - std::sys::imp::backtrace::tracing::imp::write::h1461f67be4bf68a9
   2:        0x10e6df77f - std::panicking::default_hook::{{closure}}::h6dba65b2b498d274
   3:        0x10e6df427 - std::panicking::default_hook::ha8ecbcff1f59e805
   4:        0x10e6dfc46 - std::panicking::rust_panic_with_hook::h5ceed7bd7aef311a
   5:        0x10e6dfa94 - std::panicking::begin_panic::h091a980eb2ddd29a
   6:        0x10e6dfa02 - std::panicking::begin_panic_fmt::h063a49cc71e3d103
   7:        0x10e6df967 - rust_begin_unwind
   8:        0x10e707b20 - core::panicking::panic_fmt::h59374b8a88ef3536
   9:        0x10e707c69 - core::slice::slice_index_order_fail::hec21073d5cd2d63a
  10:        0x10e43ecd8 - <core::ops::Range<usize> as core::slice::SliceIndex<T>>::index_mut::hd98460b5c92240e8
  11:        0x10e40d4ce - core::slice::<impl core::ops::IndexMut<I> for [T]>::index_mut::h133eb666c497fb7b
  12:        0x10e3c1634 - <collections::vec::Vec<T> as core::ops::IndexMut<core::ops::Range<usize>>>::index_mut::hb996221b04053b1f
  13:        0x10e3c642f - <alacritty::grid::Row<T> as core::ops::IndexMut<core::ops::Range<alacritty::index::Column>>>::index_mut::h0ec082e81cc5330b
  14:        0x10e4301ce - <alacritty::term::Term as alacritty::ansi::Handler>::linefeed::h89c021443a9d8fdf
  15:        0x10e42f712 - <alacritty::term::Term as alacritty::ansi::Handler>::input::hc794a4604e6765c8
  16:        0x10e44ab8c - <alacritty::ansi::Performer<'a, H, W> as vte::Perform>::print::h9d9d83142fbb0a8e
  17:        0x10e3e04d6 - vte::Parser::perform_action::hd299ed366d7730e1
  18:        0x10e3e0b4e - vte::Parser::perform_state_change::h5f666f5cea9cfec9
  19:        0x10e3e0ec4 - vte::Parser::advance::h7d7dc702ce94ac05
  20:        0x10e44fcfc - alacritty::ansi::Processor::advance::hc6ee283588c59dee
  21:        0x10e41c8f1 - <alacritty::event_loop::EventLoop<Io>>::pty_read::h1b59f9e710704da8
  22:        0x10e41c02f - <alacritty::event_loop::EventLoop<Io>>::spawn::{{closure}}::hcf94650ed8b8287a
  23:        0x10e44bd04 - <std::panic::AssertUnwindSafe<F> as core::ops::FnOnce<()>>::call_once::h82c52b98e7678c78
  24:        0x10e3e017f - std::panicking::try::do_call::h45001908c6796602
  25:        0x10e6e0b1a - __rust_maybe_catch_panic
  26:        0x10e3df95b - std::panicking::try::h8a297def552a6d19
  27:        0x10e3dd9c4 - std::panic::catch_unwind::hc40aeefc9b70ea57
  28:        0x10e3df11c - std::thread::Builder::spawn::{{closure}}::h1f5974490dc28140
  29:        0x10e4161b9 - <F as alloc::boxed::FnBox<A>>::call_box::h8d077e2e7f3bca57
  30:        0x10e6dee54 - std::sys::imp::thread::Thread::new::thread_start::haeb202749da670ee
  31:        0x10f948aaa - _pthread_body
  32:        0x10f9489f6 - _pthread_start
child finished with error '256'

2.) My vim now seems to be quite broken. Here is a gif:

EDIT: As something a little extra - here is a gif of the original example working - but then crashing when pressing ctrl+c

I can confirm what @d3rrial has described. I tried to comment out the is_empty code and the issue still persists.

I think if you have a theme like gruvbox in vim that isn’t rendering properly the problem becomes a little bit more interactive / visible. It seems that you just simply can’t “reach” these characters that aren’t being rendered.

I’ll try and record a gif or a video to demonstrate or maybe try to print out the on the screen what characters are in the empty space.

The problem seems to be elsewhere. I completely commented out the skipping code in term.rs but the output still looks exactly the same, so this issue is either not related to blank characters, or it’s located elsewhere in the code.

The logic for when to skip a cell is in term.rs. It uses Cell::is_empty() for checking if the cell should normally be displayed. The is_empty() logic should be updated for other non-printable characters.

Edit: perhaps using https://doc.rust-lang.org/std/primitive.char.html#method.is_whitespace