Open nilsbecker opened 7 years ago
As a heavy-handed workaround which will burn CPU cycles doing not very much, you can force a refresh. On a slower machine, may cause MacVim to feel sluggish.
if has("gui_running")
set macligatures
set guifont=Fira\ Code:h14 lsp=2
nmap <F1> :redraw!<CR>
nmap <Up> k:redraw!<CR>
nmap <Down> j:redraw!<CR>
nmap <Left> h:redraw!<CR>
nmap <Right> l:redraw!<CR>
nmap k k:redraw!<CR>
nmap j j:redraw!<CR>
nmap h h:redraw!<CR>
nmap l l:redraw!<CR>
endif
thanks, that seems indeed heavy. in fact i observed that every time i move two lines away, a redraw is triggered. so this would just need to be changed to one line away, and in addition, all redraws while remaining within the line should be removed. so an actual fix would not be more expensive than the current behavior, i think.
I also expect the behavior of using Fira Code in iTerm2.
i tried out the macligatures feature. with muliple fonts is see this:
typing
a !=
and leaving the cursor in insert mode, a somewhat broken 'not equal' ligature appears. when moving the cursor to the next (empty) line, this is repaired.moving the cursor from the
=
to the next empty line and back again a few times again reproduces the broken ligature on screen. moving the cursor further down to a nonempty line then repairs it.generally, moving the cursor onto one part of a ligature redraws the exact cursor position with the non-ligated glyph, but the adjacent positions retain chopped parts of the ligature.
it seems the problems stem from a too-local redrawing rule? better would be to redraw all characters of a ligature together, or possibly un-ligate the whole line of the cursor always.
this is the behavior with the Core renderer. with the non-core renderer i see slightly different problems. in particular when the cursor is on
=
the first part of the ligature stays black.cursorline and relativenumbers disabled. filetype was python.
this exact behavior is with Fira, other fonts gave similar results. macvim 8 patch 329.