Quentin Minster Picavet

As per the suggested workaround [there](https://github.com/tpope/vim-endwise/issues/109#issuecomment-652793808), perhaps Coq could make it easier for plugins such as vim-closer/vim-endwise to extend its mappings by not defining them as expr mappings? Something along...

I feel the proposed solution is a bit too heavy-handed, as it involves several operations on potentially large history files. Here is a proposal that works regardless of the value...

I concur @joshuafontany, feel free to include it in your PR since I can't pursue this myself right now, sorry about that.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Michał, I might be interested. Please give me a couple of weeks so I can look into it. Quentin On 2015-11-15 10:54, Michał...

FWIW, this issue is tracked in https://bugs.gentoo.org/749162, and there are patches there available for both LLVM and Clang that have been reported to fix LTO builds with GCC

This error seems to occur when there is non-UTF8 data in a register. It's easy to trigger with the clipboard: `dd if=/dev/urandom bs=4 count=1 | xclip -i -sel clip`. Then...

Here is a log of the messages sent/received by Coq leading up to the error: ``` [send]: (1, 7, None, None) [recv]: [0, 8, 'Buf_enter', []] [send]: (0, 57, 'nvim_get_current_win',...

The same data as used to trigger the log above (`cc cc cc`), but in a regular file buffer (`nvim

Ok I can trigger without peekaboo by: * putting binary data into the clipboard: `xxd -r -p

I think Neovim probably shouldn't [pack buffer lines as strings](https://github.com/neovim/neovim/blob/master/src/nvim/api/buffer.c#L1455) (since apparently they could contain raw bytes). But since it currently does, I tried: * using `raw=True` with the `Unpacker`...