beeender / glrnvim

glrnvim wraps nvim with your favourite terminal into a standalone, non-fancy but daily-usable neovim GUI.
GNU General Public License v3.0
301 stars 15 forks source link

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

Open joehannes opened 3 years ago

joehannes commented 3 years ago

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.

beeender commented 3 years ago

Does it work if the load_term_conf is false?

joehannes commented 3 years ago

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
beeender commented 3 years ago

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.

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

joehannes commented 3 years ago

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 commented 3 years ago

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

anoduck commented 2 years ago

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.

beeender commented 2 years ago

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?

anoduck commented 2 years ago

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?

beeender commented 2 years ago

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
anoduck commented 2 years ago

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!