Closed henrythor closed 1 year ago
Hey @henrythor thanks for the detailed issue (I appreciate that ๐)
When you log TERM
env variable inside and outside of tmux, what's the output?
TERM=rio
in Rio directly, TERM=screen-256color
in Rio + tmux
I see, that might be the reason, but what is weird is that this was expected to happen in kitty and alacritty as well (unless you have term=kitty
inside and outside of tmux).
This issue is also connected to this https://github.com/raphamorim/rio/issues/190#issuecomment-1693440273. Although for this case, if inside of tmux isn't term=kitty or term=alacritty, then I assume it might be a rio bug and needs further investigation.
Kitty uses TERM=xterm-kitty
.
Anything I can try to do to resolve this? Do you know of a console program that can debug raw terminal inputs?
Would a diff between verbose output of nvim's parsing of terminfo between Rio and some other terminal help? I'm not sure I understand it, is it mostly about characters nvim must emit to control the terminal, cursor location etc?
A quick workaround for this issue might be update your tmux config, in your .tmux.conf file:
set -g default-terminal "rio"
I think I might need to introduce an xterm-rio
for avoid this type of problems, kitty and alacritty does have xterm-alacritty
and xterm-kitty
not sure I follow, nvim in tmux within Rio works as intended, nvim straight on Rio is not able to add the characters that depend on ⌥ Opt or Alt Gr
I tried running tmux with rio as default-terminal and it still works
Ahh thank you for clarifying @henrythor
I pushed some changes in main, could you confirm if works for you now?
(might build a canary version soon in the CI)
I'm not really familiar with rust but I have the latest rust from Homebrew, which is 1.72.1, but your stuff is dependent on $\ge 1.73.0$.
error: package `copa v0.0.22 (/Users/henry/Dev/rio/copa)` cannot be built because it requires rustc 1.73.0 or newer, while the currently active rustc version is 1.72.1
I tried installing rust via the homebrew recipe and --HEAD
switch but the recipe is broken somehow. So I'll wait for the canary ๐
Last 15 lines from /Users/henry/Library/Logs/Homebrew/rust/03.make:
error: vendoring required, but vendor directory does not exist.
Run `cargo vendor --sync ./src/tools/cargo/Cargo.toml --sync ./src/tools/rust-analyzer/Cargo.toml --sync ./compiler/rustc_codegen_cranelift/Cargo.toml --sync ./src/bootstrap/Cargo.toml ` to initialize the vendor directory.
Alternatively, use the pre-vendored `rustc-src` dist component.
Traceback (most recent call last):
File "/private/tmp/rust-20231017-16008-r8pc8z/src/bootstrap/bootstrap.py", line 1149, in <module>
main()
File "/private/tmp/rust-20231017-16008-r8pc8z/src/bootstrap/bootstrap.py", line 1134, in main
bootstrap(args)
File "/private/tmp/rust-20231017-16008-r8pc8z/src/bootstrap/bootstrap.py", line 1093, in bootstrap
build.check_vendored_status()
File "/private/tmp/rust-20231017-16008-r8pc8z/src/bootstrap/bootstrap.py", line 1024, in check_vendored_status
raise Exception("{} not found".format(vendor_dir))
Exception: /private/tmp/rust-20231017-16008-r8pc8z/vendor not found
make: *** [all] Error 1
READ THIS: https://docs.brew.sh/Troubleshooting
rust's formula was built from an unstable upstream --HEAD.
This build failure is expected behaviour.
Do not create issues about this on Homebrew's GitHub repositories.
Any opened issues will be immediately closed without response.
Do not ask for help from Homebrew or its maintainers on social media.
You may ask for help in Homebrew's discussions but are unlikely to receive a response.
Try to figure out the problem yourself and submit a fix as a pull request.
We will review it but may or may not accept it.
An advice would be avoid install rust with homebrew often it leads to issues for me. Specially whenever building different toolchains/targets
Are you using macos? If yes, you can download the canary version here https://github.com/raphamorim/rio/releases/tag/canary
Oki, cool. The last Canary was built 8 hours ago but I've seen you made a commit disabling kitty keyboard protocol to main since then, isn't that the relevant commit?
Yes, good catch. It should have been a bit more "fresh" canary ๐ Will look tomorrow why didn't triggered
Looks like disabling kitty keyboard protocol has fixed for other similar issues like yours #222 . Will be closing this issue for now but let me know anything
OS: macOS Sonoma 14.0 (23A344) Rio: 0.0.22 installed via
brew install --cask rio
nvim: stable 0.9.4I'm not quite sure what's happening under the hood here, but I have an ISO keyboard with Nordic/Icelandic layout and I'm trying to use nvim with Rio.
To type
{
in insert mode, for example, I would press ⌥ Opt + 7 (Alt Gr + 7 on PC keyboards).When I use nvim in Rio, nvim will exit insert mode instead of adding the curly bracket to the screen buffer. If I use Ctrl + V to see the literal key input it will show
<M-{>
instead of{
. Using ⌥ Opt + < to input|
will similarly show<M-Bar>
.This does not happen in kitty, alacritty, Terminal, etc. It does not happen if I run nvim from within tmux in Rio. It does not happen with vim and Rio. So I'm thinking it's something to do with the way nvim interprets terminfo.
Any ideas how I can fix this? Will I have to map all the Meta/Alt sequences to the literal keys in nvim? Is this an nvim bug?
Here is nvim's parsing of terminfo: