Nixpkgs: No colour in alacritty when installed via `configuration.nix`

Created on 17 Oct 2019  路  28Comments  路  Source: NixOS/nixpkgs

Describe the bug
There is no colour in neovim in alacritty if alacritty is installed from configuration.nix. alacritty has to be installed via nix-env for colours to work.

To Reproduce
Steps to reproduce the behavior:

  1. Install alacritty in configuration.nix only
  2. Run neovim: no colours

Please keep in mind that I am using neovim as an example. The problem doesn't seem to be related to it in any way.

Expected behavior

Neovim has colours.

bug nixos package (update) upstream fix

All 28 comments

@filalex77 @Mic92

By "installing in configuration.nix", you mean adding pkgs.alacritty to environment.systemPackages? Also, what version of alacritty do you have installed? (preferably specify both the configuration.nix and nix-env-provided versions)

I have alacritty installed via home-manager in home.packages:

$ which alacritty                                                                                           
/home/brightone/.nix-profile/bin/alacritty

Colors work fine in both vim and nvim:

image

Strangely enough, when I install alacritty via environment.systemPackages, colours seem to work in vim, but don't work in nvim! :eyes:

By "installing in configuration.nix", you mean adding pkgs.alacritty to environment.systemPackages?

yes

Also, what version of alacritty do you have installed? (preferably specify both the configuration.nix and nix-env-provided versions)

Both are alacritty 0.3.3

Strangely enough, when I install alacritty via environment.systemPackages, colours seem to work in vim, but don't work in nvim

This is the problem. I retested, and the colours work in vim regardless of the way it is installed so maybe this problem might be specific to nvim then.

When running nvim from alacritty installed via environment.systemPackages, running the command :echo &term returns builtin_ansi. (Please keep in mind that the environment variable TERM is set to alacritty.

When running nvim from alacritty installed via nix-env, running the command :echo &term returns alacritty.

From the nvim documentation:

"builtin_x" means one of the |builtin-terms| was chosen, because the expected terminfo file was not found on the system.

Okay, then it's a problem with terminfo recognition. I'll look into it.

According to :help term.txt, nvim uses the unibilium library to parse terminfo.

Can you please run sudo nixos-option environment.pathsToLink and post the output? @NilsIrl

/share/terminfo should be linked:

$ sudo nixos-option environment.pathsToLink | rg term
  "/share/terminfo"
  "/nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/config/terminfo.nix"

Here is another hypothesis:

The TERMINFO_DIRS's (colon separated path list) first path is invalid when alacritty is installed via environment.systemPackages as the path is ~/.nix-profile/share/terminfo. When unibilium reaches an invalid path it stops.

$ ls ~/.nix-profile/share/terminfo
ls: cannot access '~/.nix-profile/share/terminfo': No such file or directory

So if this is true, there are 2 fixes, make so that the TERMINFO_DIRS environment variable only contains valid paths or make it so unibilium doesn't stop on invalid paths.

Obvious it would be best if the 2 fixes are applied.

I think that TERMINFO_DIRS is fine:

$ sudo nixos-container create 71300 --config '
  environment.systemPackages = with pkgs; [ alacritty neovim ];
'
host IP is 10.233.1.1, container IP is 10.233.1.2

$ sudo nixos-container start 71300

$ sudo nixos-container root-login 71300

[root@71300:~]# echo $TERMINFO_DIRS
/root/.nix-profile/share/terminfo:/etc/profiles/per-user/root/share/terminfo:/nix/var/nix/profiles/default/share/terminfo:/run/current-system/sw/share/terminfo

So, /run/current-system/sw/share/terminfo is in TERMINFO_DIRS. And alacritty files are there:

[root@71300:~]# find /run/current-system/sw/share/terminfo/ -name '*alacritty*'
/run/current-system/sw/share/terminfo/a/alacritty+common
/run/current-system/sw/share/terminfo/a/alacritty
/run/current-system/sw/share/terminfo/a/alacritty-direct

So, /run/current-system/sw/share/terminfo is in TERMINFO_DIRS. And alacritty files are there

Yes, but my guess is that unibilium looks at each path sequentially and if a path is invalid it fails totally and doesn't continue.

In your example with the container, the first path (/root/.nix-profile/share/terminfo) is invalid (the directory doesn't exist).

Okay, I see your point, thanks.

Seems to be set in nixos/modules/config/terminfo.nix. Maybe @worldofpeace can help?


Also, related PR to neovim/unibilium that caused this issue: https://github.com/neovim/unibilium/pull/12

Actually by hypothesis might be wrong because running this:

$ export TERMINFO_DIRS=/run/current-system/sw/share/terminfo

doesn't fix the problem, nvim still doesn't have colours.

Also, related PR to neovim/unibilium that caused this issue: neovim/unibilium#12

It seems to me the version shipped with NixOS is from mauke/unibilium as shown by https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/unibilium/default.nix.

Yeah, looks like the neovim derivation uses it. Meaning I can't put my finger on the issue just yet.

The problem actually probably has to do with alacritty/the way it is installed on NixOS because with Kitty, I don't have the same problem.

https://github.com/NixOS/nixpkgs/issues/71300#issuecomment-559143237 sounds like a very very accurate evaluation to me. But I don't think we should touch the global nixos environment just because it doesn't continue to recurse after it finds an invalid path. Additionally, I don't think there's anything we could do in https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/config/terminfo.nix to change this.

You should probably take issue with the upstream project.
I guess what you could do for now is revert https://github.com/neovim/unibilium/pull/12 as a downstream patch also.

Here is some random observations I have done that might or might not be interesting:

For kitty: /run/current-system/sw/share/terminfo/x/xterm-kitty -> /nix/store/n0fkik6g64740fcfwphiabnd7shj85am-kitty-0.14.6-terminfo/share/terminfo/x/xterm-kitty

where as for alacritty: /run/current-system/sw/share/terminfo/a/alacritty -> /nix/store/zp8v7wkbplvmzyds87icn1rk070hizdc-ncurses-6.1-20190112/share/terminfo/a/alacritty

This is especially strange considering these directories exists:

$ ls /nix/store/*alacritty*terminfo
/nix/store/2ki5rvfrh0lzz78m00ggppiv1xxzbrkg-alacritty-0.3.3-terminfo:
share

/nix/store/32yzisc71yn3lan4f1b1f4fbgm9zgjgp-alacritty-0.3.3-terminfo:
share

/nix/store/8apxkx80v9s6vwc4s6dpqss98197j65z-alacritty-0.3.3-terminfo:
share

/nix/store/b4192d8wbqap9pv9pcq414a9z9haqpy5-alacritty-0.3.3-terminfo:
share

/nix/store/jnvkygqhci84rfgwlrbc2scf8p7mnfax-alacritty-0.3.3-terminfo:
share

/nix/store/l7l50g0s7mnsik1qf6b439jgsh75xigp-alacritty-0.3.3-terminfo:
share

/nix/store/m8zhybd1kzm4fmxxqzbm60lnzl0x5lqy-alacritty-0.3.3-terminfo:
share

/nix/store/myil59q6lmmiwg7d0l41yhp7g0k6ycfw-alacritty-0.3.3-terminfo:
share

/nix/store/r2wz47kyb1ddrzwajhgfmmpn9w1vvjif-alacritty-0.3.3-terminfo:
share

There is also something strange with the terminfo files themselves (notice the 32 bit thing):

$ file /nix/store/2ki5rvfrh0lzz78m00ggppiv1xxzbrkg-alacritty-0.3.3-terminfo/share/terminfo/a/alacritty
/nix/store/2ki5rvfrh0lzz78m00ggppiv1xxzbrkg-alacritty-0.3.3-terminfo/share/terminfo/a/alacritty: Compiled terminfo entry "alacritty"
$ file /nix/store/zp8v7wkbplvmzyds87icn1rk070hizdc-ncurses-6.1-20190112/share/terminfo/a/alacritty
/nix/store/zp8v7wkbplvmzyds87icn1rk070hizdc-ncurses-6.1-20190112/share/terminfo/a/alacritty: Compiled 32-bit terminfo entry "alacritty"
$ file /nix/store/n0fkik6g64740fcfwphiabnd7shj85am-kitty-0.14.6-terminfo/share/terminfo/x/xterm-kitty
/nix/store/n0fkik6g64740fcfwphiabnd7shj85am-kitty-0.14.6-terminfo/share/terminfo/x/xterm-kitty: Compiled terminfo entry "xterm-kitty"

Ok, so the problem is linked with observations that was done in https://github.com/NixOS/nixpkgs/issues/71300#issuecomment-559186017.

doing the following fixed it:

$ export TERMINFO_DIRS=/nix/store/jnvkygqhci84rfgwlrbc2scf8p7mnfax-alacritty-0.3.3-terminfo/share/terminfo:$TERMINFO_DIRS

So the following link: /run/current-system/sw/share/terminfo/a/alacritty -> /nix/store/zp8v7wkbplvmzyds87icn1rk070hizdc-ncurses-6.1-20190112/share/terminfo/a/alacritty is erronous

Should we delete the erroneous alacritty* files from the ncurses output? Or is there a way to make alacritty's terminfo output the preferred one? (e.g. linked into the environment)

The thing that bothers me is that why was it there in the first place and how is it that it is erroneous without anyone noticing and if it really is erroneous.

Does it mean this is a bug in upstream ncurses?

Might be related to this commit: https://github.com/mirror/ncurses/commit/22a4b929f47f85588dc07fddf98b09776cec658f

@NilsIrl I made a PR that should make terminfo files provided by alacritty override the ones provided by ncurses. Could you please test it out? Thanks!

One could also see if there is any difference between alacritty and the ncurses version of the termfile: https://raw.githubusercontent.com/mirror/ncurses/master/misc/terminfo.src
Than we could add the patch for ncurses if it turns out to be broken.

alacritty|alacritty terminal emulator,
    rs1=\Ec\E]104\007, use=xterm+256color,
    use=alacritty+common,

The 3 lines of terminfo.src are indeed a lot different than this:

https://github.com/jwilm/alacritty/blob/36185c47533d6189c9116df7a41a13766ca2b40c/extra/alacritty.info#L1-L13

And that's ignoring alacritty+common

This is no longer a problem for me on release-20.03.

I'm also on 20.03 but I'm still having this issue.

Edit: nvm, fixed it by unsetting my TERMINFO_DIRS env var which I had set in my shell config

Was this page helpful?
0 / 5 - 0 ratings

Related issues

grahamc picture grahamc  路  3Comments

spacekitteh picture spacekitteh  路  3Comments

ayyess picture ayyess  路  3Comments

copumpkin picture copumpkin  路  3Comments

yawnt picture yawnt  路  3Comments