dotfiles/nvim/ at main · jni.codes/dotfiles · Tangled

jni.codes / dotfiles

1

dotfiles

1

dotfiles / nvim /

at main 2 files

Juan Nunez-Iglesias Fix opening in referred code in new nvim window 7d ago

Fix opening in referred code in new nvim window From Claude: Root cause (two independent bugs): 1. Ghostty eats the +cmd argument. Ghostty's -e flag scans every token for a leading + (its own +action syntax, e.g. +new-window) and silently drops any it doesn't recognize — including nvim's +call cursor(...). I confirmed this by launching ghostty and dumping the child's actual argv: +call cursor(5,10) vanished completely, leaving only nvim and the filepath. Since the jump command never ran, nvim's own BufReadPost autocmd (nvim/init.lua:231-240, restores cursor to the last-visited " mark) was the only thing setting the cursor — explaining exactly what you saw: file opens fine, cursor lands wherever you last left off in that file. 2. Off-by-one indexing. LSP positions are 0-indexed; Vim's cursor() is 1-indexed. This was real but secondary — masked by bug #1 since the whole command was being dropped anyway. Fix (nvim/init.lua): added a shared open_in_new_window(filepath, line, col) helper that shell-quotes the +cmd and filepath into a single string and runs it via ghostty -e sh -c '<cmd>' — so the +-prefixed token is buried inside one argv element instead of being its own, and survives ghostty's parser. Both gd and the quickfix <CR> handler now use it.

1 week ago

Add virtcolumn for vertical marker at 80c

3 weeks ago