glrnvim icon indicating copy to clipboard operation
glrnvim copied to clipboard

nvim sub-tools (path) like bat (for file preview in fzf) broken

Open joehannes opened this issue 3 years ago • 10 comments

I'm on macOS BigSur I installed via cargo build, then creating an executable.sh with

#!/bin/zsh

cd ~/.local/git/glrnvim
cargo run

exit 0

Hooking this skript up via Alfred Powerpack to a Shortcut ... I get my glrnvim with this glrnvim.yml

backend:
  alacritty
exe_path:
  /Users/joehannes/.cargo/bin/alacritty
load_term_conf:
  true

Everything seemed to work, until I used a regular fuzzy finding preview and the preview was broken. That's glrnvim specific somehow, because it works in pure alacritty/nvim.

Bildschirmfoto 2021-04-03 um 19 43 54

It's a pity, I was happy for a sec, but then, I can't use it like that.

joehannes avatar Apr 03 '21 18:04 joehannes

Does it work if the load_term_conf is false?

beeender avatar Apr 04 '21 06:04 beeender

no, same issue. also just tried to run my starter script (which then starts alacritty and glrnvim) from iterm2 (where I know I got zsh as default shell), same result, also with this setting=false.

Bildschirmfoto 2021-04-04 um 11 28 22

joehannes avatar Apr 04 '21 09:04 joehannes

I just added some log in #37 , just pull the latest master to use it. To start the glrnvim with debug log enabled:

RUST_LOG=debug cargo run

You will see something like:

[2021-04-04T14:33:13Z DEBUG glrnvim] Start command: "/usr/bin/alacritty" "--config-file" "/tmp/.tmpjoncSd" "--class" "glrnvim" "--working-directory" "/home/cc/repo/glrnvim" "-e" "nvim" "+set termguicolors" "+set title" "--cmd" "let g:glrnvim_gui=1"

That is the command line which glrnvim is using to start alacrity + nvim. I guess you will have the same problem by running that command line alone.

  • "--config-file" "/tmp/.tmpjoncSd" is the generated alacrity config file, check that file to see if there is anything suspicious.
  • Also, the "+set termguicolors" could be another one may cause display issues, try to remove it to see if it helps.
  • 0d52ae96 solved a display with MAC long time ago, maybe something changed in BigSur? Do TERM_PROGRAM and TERM_PROGRAM_VERSION still exist in the env for BigSur?

I don't have a BigSur right now, I will try to reproduce the problem if I can find one.

beeender avatar Apr 04 '21 14:04 beeender

zsh output:

[2021-04-04T14:43:34Z DEBUG glrnvim] unset $TERM_PROGRAM
[2021-04-04T14:43:34Z DEBUG glrnvim] unset $TERM_PROGRAM_VERSION
[2021-04-04T14:43:34Z DEBUG glrnvim] Start command: "/Users/joehannes/.cargo/bin/alacritty" "--config-file" "/var/folders/m4/fclbk1x959l1cfy36prwjwq40000gp/T/.tmp5dgjMe" "--class" "glrnvim" "--working-directory" "/Users/joehannes/.local/git/glrnvim" "-e" "nvim" "+set termguicolors" "+set title" "--cmd" "let g:glrnvim_gui=1"

also, it's apparently not about finding the tool for the preview or its path (anyway) ... commenting this line in my init.vim

let $FZF_DEFAULT_OPTS = '--layout=reverse --preview="bat --style=numbers --color=always --line-range :500 {}"'

doesn't change a thing, cat is not previewing in the same misbehavior

also, i tried to comment my set termguicolors in my init.vim ... nothing changes, even the debug output of yours insists on "+set termguicolors"

joehannes avatar Apr 04 '21 14:04 joehannes

also, just to let you know, was just playing around with starting it from more built in terminal apps like 'Terminal' ... while trying to run 'cargo run' glrnvim in 'Terminal' it all of a sudden did a recompile which it failed to finish with ...

error[E0433]: failed to resolve: could not find `__private` in `_serde`
  --> src/config.rs:26:5
   |
26 |     #[serde(default)]
   |     ^ not found in `_serde::__private`

I got that one before as well, but on cargo install --path . only, not on cargo run ... Cheers

joehannes avatar Apr 04 '21 15:04 joehannes

Same issue as above, with alacritty as well. Glrnvim does not read environment variable $PATH for some reason and is unable to locate rust applications located in ~/.cargo/bin.

This issue might be specifically a Unix issue, since it occurs both on Mac and OpenBSD.

anoduck avatar Sep 08 '22 05:09 anoduck

Glrnvim does not read environment variable $PATH for some reason and is unable to locate rust applications located in ~/.cargo/bin.

I just tried by setting PATH and run an executable by !executable_name in glrnvim. The $PATH I set before can be recognized. Could you please let me know how did you reproduce the problem?

beeender avatar Sep 09 '22 10:09 beeender

I discovered it was more than just rust based applications, it is safe to assume it is all user level additions to $PATH, and whether it was alacritty or kitty, made no differentce.

I am using lua to configure my init file. The directory, ~/.cargo/bin, is most definitely in my shell path, so I am assuming you are referring to defining $PATH in neovim, which I was unaware it was even possible to do so. How exactly is that done?

anoduck avatar Sep 09 '22 13:09 anoduck

so I am assuming you are referring to defining $PATH in neovim, which I was unaware it was even possible to do so. How exactly is that done?

What I tried is nothing special:

PATH=/new/path:$PATH glrnvim

Then in glrnvim:

!some_executable_in_new_path

beeender avatar Sep 13 '22 03:09 beeender

I am much grateful for your patience and generosity.

No less than twenty minutes ago, a benevolent reddit user gave me the answer on how to accomplish this in lua:

vim.env.PATH = '/path/to/additional/bin' .. '/path/another/bin' .. vim.env.PATH

It has worked like a charm, and glrnvim is back in the driver's seat. Thanks for all the work you do!

anoduck avatar Sep 13 '22 06:09 anoduck