Goyo doesn't recover italic for base vim configuration

[oblitum]

Opening a markdown file with the following content:

_italic-text_

:call SyntaxAttr() (check following plugin list) with the cursor over "italic-text" gives:

• group: markdownItalic->htmlItalic gui=italic.

After :Goyo it's the same, but after leaving :Goyo the highlighting group changes to:

• group: markdownItalic->htmlItalic

and the text display ceases to be italic. This was tested with the following minimal .vimrc:

" VIM-PLUG Setup {{{

" Automatic installation {{{
if empty(glob('~/.vim/autoload/plug.vim'))
    silent !mkdir -p ~/.vim/autoload
    silent !curl -fLo ~/.vim/autoload/plug.vim
        \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
    au VimEnter * PlugInstall
endif
" }}}

call plug#begin('~/.vim/plugged')

" Plugins {{{
Plug 'junegunn/goyo.vim'
Plug 'vim-scripts/SyntaxAttr.vim'
" }}}

call plug#end()

" }}}

au! User GoyoLeave
au  User GoyoLeave nested source $MYVIMRC

Notice that the solution on https://github.com/junegunn/goyo.vim/issues/44 to reload .vimrc on GoyoLeave has already been tried without success.

[ultimatecoder]

@oblitum I am confirming this behavior in my vim editor. I am able to reproduce it.

[oblitum]

This plugin is nice but the highlighting issues are so many... I've stopped using it but I'd like to suggest to modularize and turn optional anything that's highlighting related. So that one could still get Zen mode window magic without anything highlighting related being touched.

[junegunn]

Let me close this then.

[oblitum]

@junegunn Sorry if it sounded offensive, was not my intention. Just wanted to leave the suggestion.

[junegunn]

No offence taken, the issue doesn't bother me and I'm not going to put my time into it.

[oblitum]

OK, nice. I was thinking of tuning a fork in that sense, if I manage to put this behind a flag I'll offer a pull request.

[oblitum]

Besides this patch I had in my fork, there was a missing piece, I guess this is the remaining part that cause this:

execute 'colo '. get(g:, 'colors_name', 'default')

This is the reason this issue exists.

[oblitum]

For anyone interested in Goyo's Zen mode but suffer from highlighting issues like this one and others.

With https://github.com/oblitum/goyo.vim/commit/f36555e417d2c6dad6a3d969f320ff5b26d7b7f9 and https://github.com/oblitum/goyo.vim/commit/034479bc30641c09d3bef05cd0b6e84befca1fd9 I've disabled Goyo from touching highlighting.

I then remove the UI artifacts manually from GoyoEnter/GoyoLeave as per https://github.com/junegunn/goyo.vim/issues/71#issuecomment-250594184:

• oblitum/dotfiles@4d4169a#.vimrc

[junegunn]

Glad to hear that you found your solution, but that means you can no longer switch color schemes without changing the related code.

Also I can't reproduce the problem with my config. Since reloading color scheme shouldn't cause this issue, I believe the problem lies in your source $MYVIMRC, which shouldn't be necessary. If you're concerned about losing custom highlights there are better ways to handle that, i.e. autocmd ColorScheme.

[oblitum]

@junegunn I realize the limitations in that but I prefer this way much more, I change colorscheme quite rarely, and this is lighter as there's no full colorscheme reload.

If you know an alternative solution, I'd be glad to know, I have no idea besides the one I've come with.

[oblitum]

Also, I do care about the custom highlightings, but for this issue I preferred to focus solely on the problem with native Vim highlighting.

[oblitum]

Also, it may have not been clear formerly. The issue happens both with and without source $MYVIMRC. You have to have a terminal with italics, for this case it's italics specific.

[junegunn]

The issue happens both with and without source $MYVIMRC.

I see I was mistaken. But let me clarify what's going on here.

• We don't need Goyo at all to reproduce the issue. Simply switching to any color scheme will cause the problem.
• But why? Why does changing a color scheme affect highlighting attributes? I would say that this is a bug of Vim itself. Not Goyo.

[oblitum]

I also think it looks as a Vim issue, but fact is that it's relatively easy to evade: just avoid full colorscheme reload. I think that Goyo would be quite less problematic if it patched the current colorscheme to achieve Zen mode and unpatched it on leave (like I do in my .vimrc). It would have to store the highlighting groups patched for posterior recovery on turning off, and if it limited itself to just patch those groups that regard to removing artifacts, which are just a handful, it would be quite rare that any issue would happen with their patch/recovery. There could be levels of tranquilize, just bare like this just described (the default one), and more intrusive ones (like the one currently provided by upstream tranquilize), or none at all, leaving the task to the user on GoyoEnter/GoyoLeave.

Ultimately this what I'd wish to do in my fork so that I'd not need to do it hardcoded from GoyoEnter/GoyoLeave, but I've left this for a later time.

[oblitum]

I've fixed this at https://github.com/oblitum/goyo.vim/commit/04f5bfcc929ca1f32828f2012560b3c8f33ac887.

I recover colorscheme from a :redir backup of color groups Goyo needs to patch, instead of reapplying the user's colorscheme entirely.

I can make a pull for it if there's interest.

[nickwynja]

@oblitum Your fix in https://github.com/oblitum/goyo.vim/commit/372a2d458555f5ae56b5ef9156ced6e28fe07fac seems to work nicely to solve the italics issue. I need to manually run set foldcolumn=0 and set signcolumn=no after entering Goyo-mode to clean up some additional artifacts. It doesn't appear to be working to run these in goyo_enter() though.

I see you've adjusted the grp here: https://github.com/oblitum/goyo.vim/commit/372a2d458555f5ae56b5ef9156ced6e28fe07fac#diff-76b494d73254bc11a2d717fdee9e5daaR135. Maybe that could effect this? I'll try to dig further on my own tomorrow.

[oblitum]

@nickwynja yes, I've removed some groups on my own because disabling them don't play nice in my setup, I should have done that in a separate commit. You just need to add them back to the list. Or use my master. Besides that fix, I also have an additional commit where I deprecate GoyoEnter for GoyoEnterPre and GoyoEnterPost, for more precise control of autocmd before entering Goyo and after entering it. Original GoyoEnter is like GoyoEnterPost.

[oblitum]

I will rebase my master and have that part in a separate commit.

[oblitum]

@nickwynja I've rebased my master and isolated the fix while keeping the original groups at https://github.com/oblitum/goyo.vim/commit/04f5bfcc929ca1f32828f2012560b3c8f33ac887 (newer fix at https://github.com/oblitum/goyo.vim/commit/e6def71a90498837fcd256e53dfbd931d57715f4, see https://github.com/oblitum/goyo.vim/issues/1#issuecomment-441740261).

(I've also updated the link on the comments above)

[nickwynja]

@oblitum Thanks! This is working better. There is a minor issue I'm running into with restoring highlights links:

Error detected while processing function goyo#execute[20]..<SNR>143_goyo_off[59]..<SNR>143_restore:
line   10:
E413: Too many arguments: ":highlight link SignColumn ctermfg=12 ctermbg=242 guifg=Cyan guibg=Grey LineNr"

But replacing this substitute with the following seems to work for me:

execute 'hi link ' . substitute(cmd, '\(\w\+\)\s.*links\s\+to\s*', '\1 ', '')

[oblitum]

@nickwynja hmm, that fix is not good, you're not recovering highlight links correctly. If you care, please open an issue in my fork referring to the colorscheme you're using. As this regex worked for all my colorschemes, which are not many, I thought it would work for all forms of output Vim/NeoVim gives when calling hi group, to recover it later from that output, but the output may differ depending even on your window size, I try to cover that but dunno what your case is bringing of new.

[oblitum]

Hmm, correction, your substitute may in fact be fine and fixing the issue, but (it's in fact hiding a bug). I'd still like to check the issue myself.

[pappasam]

@oblitum This fixes the issue for me:

function! s:goyo_leave()
  syntax off
  syntax on
endfunction

autocmd! User GoyoLeave nested call <SID>goyo_leave()

I'm honestly not sure why this works over other options, but you can thank this post for the solution: https://stackoverflow.com/a/8674739

[oblitum]

@pappasam thx, that's good to know! Though I still prefer my solution because I avoid fully reloading colorschemes and syntax, which means it's less intrusive and avoids blinking.