[vim/vim] Ruler line appears twice (Issue #18181)
girish
girishji created an issue (vim/vim#18181)Steps to reproduce
Not able to reproduce consistently. This is on MacOS. It appears that when writing to SSD takes longer than usual, ruler gets printed twice. See the picture below.
Also, notice "writtenkk". I pressed k twice quickly after writing to file. It appears that cursor has not left the command-line. Is there a race condition where Vim stays in command-line while waiting for write to finish but also processes keys from typehead?
Expected behaviour
Ruler should be printed once.
Version of Vim
Environment
MacOs
Logs and stack traces
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18181)I don’t see this issue in Neovim. When the SSD takes longer to write (a few hundred milliseconds), Neovim simply stalls briefly and then resumes normally. Under the same conditions, Vim’s display breaks. Lines go missing or are duplicated, making it unusable. I’ve temporarily switched to Neovim because of this.
@zeertzjq, does Neovim handle stalled writes (especially when other commands are pending) differently from Vim on macOS?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18181)are you using any background jobs (in Vim I mean)? I have seen similar behavior, when e.g. using heavy jobs while evaluating the statusline and then redrawing brakes. Having said that, I have never noticed this behaviour on a light system when not using a fancy statusline
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18181)I am not using any job_start() in my config files, but I guess there are other I/O-heavy processes running at the same time. This problem does not happen on a 'light' system. I am not using statusline (unless there is split window, which I don't use too often), but I use the ruler. My rulerformat config looks complex, and maybe this is the issue. In any case, Vim should wait until SSD write is done, no?
" Ruler
set laststatus=0 ruler
if !has('nvim')
set highlight-=S:StatusLineNC highlight+=Si
endif
augroup ruler_toggle
autocmd!
autocmd WinEnter,BufEnter * setl rulerformat=%65(%=\ %-t%{&modified?'[+]':''}\ \ %{bufexists(bufnr('#'))&&(bufname(bufnr('#'))!='')&&bufnr('#')!=bufnr('%')?'('.(fnamemodify(bufname(bufnr('#')),':t').(getbufvar(bufnr('#'),'&modified')?'[+]':'').'#)\ '):''}%y%{&ft==''?'':'\ '}%l,%c%V\ %P%)
autocmd WinEnter,BufEnter * setl statusline=%=%-t%{&modified?'[+]':''}\ ≡\ %{bufexists(bufnr('#'))&&(bufname(bufnr('#'))!='')&&bufnr('#')!=bufnr('%')?'<'.(fnamemodify(bufname(bufnr('#')),':t').(getbufvar(bufnr('#'),'&modified')?'[+]':'').'#>\ '):''}%y%{&ft==''?'':'\ '}%l,%c%V\ %P\
autocmd WinLeave * setl statusline=%=\ %-t\ |:
augroup END
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18181)actually job_start() should be fine, what is known to cause problems is using system(). But your statusline/rulerformat looks light enough. Would you be running any other expensive autocommands? I don't believe slow writing to a SSD should be the issue per se, Vim has been working fine for me on slow filesystems (sshfs, etc). It rather smells like something interrupting the redrawing. But just in case, does setting fsync or swapsync make any difference?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#18181)does Neovim handle stalled writes to SSD (especially when other commands are pending) differently from Vim on macOS?
For writing actual buffer content Nvim seems to use the same write_eintr() function as Vim. However for writing metadata or renaming files Nvim uses some libuv functions, but I don't these are what matters here.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18181)But Neovim doesn't set 'fsync' by default, IIRC?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18181)You're right, only Vim sets fsync by default. This seems reckless on their part, especially for older filesystems which only journal metadata. Laptops should be OK since they have battery power, and SSDs have capacitors as well. Also, Apple admits that fsync() in APFS is slower than linux, and can stall UI. I suppose turning off fsync is OK for my laptop, although I prefer full flush when I write (just in case).
On a different note, why is fsync interfering with refresh? While Vim is stalled on write-to-SSD, all the characters I type appear on screen. It is refreshing parts of the screen instead of waiting for fsync to finish.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18181)Sorry, verified again, Neovim does set fsync by default.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18181)Ah, it seemed that default was reverted again in Neovim neovim/neovim#26039
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18181)This now happens often on a 'cold' system (with light cpu load and no I/O). Something about my macbook's SSD is triggering this so often. Unfortunately I do not have a lot of bandwidth ATM to dig into this. @chrisbra do you remember anything that might have changed in this area (bufwrite.c for ex.)? Hard to imagine this type of issue persisting over years. As I mentioned earlier Neovim does not have this problem.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#18181)I am not aware of any changes affecting buffer writing, sorry
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
girish
girishji left a comment (vim/vim#18181)I switched to status-line (from ruler) and this problem is alleviated a little bit. Vim still redraws screen wrongly while waiting for disk write to finish (when I press 'j' after a shortcut to write to disk, the letter 'j' will appear on the command line, instead of moving the cursor one line down). Unlike the ruler, status-line does not appear twice. There seems to be 2 bugs: 1) previous ruler not erased before drawing a new one -- leaving the whole screen unusable, 2) redrawing screen and inserting typed characters on the command-line while waiting for disk write to return, instead of simply waiting not reading the type-head.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.