parsonsmatt / intero-neovim

A neovim plugin for Intero, forked from ghcmod-vim
218 stars 28 forks source link

Most commands don't work and glitch the buffer #153

Open hasufell opened 6 years ago

hasufell commented 6 years ago

with neovim-0.3.0, stack and the following intero-neovim config

    " Intero starts automatically. Set this if you'd like to prevent that.
    let g:intero_start_immediately = 1

    " Enable type information on hover (when holding cursor at point for ~1 second).
    let g:intero_type_on_hover = 1

    " Change the intero window size; default is 10.
    let g:intero_window_size = 15

    " Sets the intero window to split vertically; default is horizontal
    let g:intero_vertical_split = 1

    " OPTIONAL: Make the update time shorter, so the type info will trigger faster.
    set updatetime=1000

    map <silent> <F6> <Plug>InteroGenericType

Trying to get type information moves the cursor up, then starts doing weird stuff to the buffer, moving lines around and whatnot.

InteroGoToDef seems to work occasionally, InteroOpen too, InteroLoadCurrentFile doesn't. The files are without error.

Plain ghc-mod works perfectly.

parsonsmatt commented 6 years ago

Can you be more precise about what goes wrong? eg:

When I do :InteroType, it moves up a line

Are the errors reliable or deterministic?

hasufell commented 6 years ago

Are the errors reliable or deterministic?

What errors? The buffer is just totally messed up, documentation gets mixed with code, the cursor slowly moves up.

parsonsmatt commented 6 years ago

That's extremely weird! Would you be willing to post screenshots?

parsonsmatt commented 6 years ago

I am unable to replicate with that configuration and neovim-0.3.1-DEV

hasufell commented 6 years ago

peek 2018-06-14 20-57

This happens on pressing the hotkey for type info (which is properly configured). I can't say whether that's actually related to the hotkey. I'm guessing it's something with the GHCi repl.

You can see my whole config here and here.

bradlarsen-works commented 6 years ago

I suspect this glitching buffer issue may actually be an issue with neovim 0.3*. I see similar broken redrawing behavior in neovim after upgrading from 0.2 to 0.3.1, and not just with intero-neovim. (Perhaps https://github.com/neovim/neovim/issues/8768 or https://github.com/neovim/neovim/issues/8490; https://github.com/neovim/neovim/labels/display may be useful too.)

I think the text slowly scrolling up is actually happening as a result of the output of the Intero bufferin neovim causing the screen to be badly redrawn, a line at a time, as Intero loads modules of your Haskell project. @hasufell, does pressing ctrl-L redraw the screen for you? It does for me. I also found that opening the Intero buffer in a split seems to avoid the glitching buffer / redrawing problems.

I thought that a tmux interaction might be involved, but running outside of tmux makes no difference for me. When I run with neovim 0.2 again on the same system, I don't experience any of the redrawing problems. For now, I'm back on neovim 0.2.

bradlarsen-works commented 6 years ago

I've also noticed that for me, most intero-neovim commands were not working properly for me out-of-the box; moving aside my ~/.ghci, which sets a custom prompt, fixed most of that.

There is also the g:intero_prompt_regex setting which is probably relevant.

justinmk commented 6 years ago

https://github.com/neovim/neovim/issues/8768 only fixes a bug present on Nvim HEAD (0.3.2). It's not related to anything in 0.3.1 or earlier.

Regarding the original reports here: try a different terminal emulator, and check that $TERM is correct. (Don't do only one of these things, do both.)

hasufell commented 6 years ago

Terminal emulator is totally unrelated. This even happens in neovim-gtk.

hasufell commented 6 years ago

It seems you really have to have the buffer window open, otherwise everything breaks.

alex-kononovich commented 6 years ago

I can confirm the problem on Neovim 0.3.1 as well as on 0.3.2-dev - screen is glitched as soon as I save the buffer (which triggers typecheck). I can clear screen with Ctrl-L, and the problem does not appear if Intero buffer window is open.

I have custom GHCi prompt, but disabling that didn't fix the problem.

For now, I'm back to Neovim 0.2.2

amarshall commented 6 years ago

I see this as well on Neovim v0.3.1. I don’t even have to do anything after opening a file (no cursor movement, no insertion—though I am opening to a saved cursor position a bit down the file). Intero auto-starting alone corrupts the buffer. Possibly has to do with entering/exiting the Neovim terminal? I end up with the lines drawn following line 46 being line 35 on. In some cases, I can actually get the cursor into the status line and command line just be going down line-by-line with j.

Testing in both Kitty with xterm-kitty and iTerm2 with xterm-256color, and both exhibit the issue. CTRL L does redraw correctly.

parsonsmatt commented 6 years ago

This seems like an upstream bug in Neovim. I don't think we're doing anything weird with our terminal emulator communication.

hasufell commented 6 years ago

This seems like an upstream bug in Neovim.

Why? Have you verified that this happens in other plugins too?

nytopop commented 5 years ago

Found the bug, it was introduced in https://github.com/neovim/neovim/commit/fe5f38d8bd54248e4ea327a7f6ca52646799f3a4. Adding back redraw_buf_later(buf, NOT_VALID); fixes it in nvim master, but regresses w.r.t. https://github.com/neovim/neovim/issues/8290.

This issue may also be related to https://github.com/neovim/neovim/issues/8723, not sure though.

edit: I'm attempting to put together a patch, it might take some time though as I'm not very well versed in the codebase or C.

justinmk commented 5 years ago

https://github.com/neovim/neovim/issues/8723 is fixed on Nvim 0.4.x .