Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SoftPencil on, then off, then on again -breaks navigation mappings #96

Open
pooriajr opened this issue May 8, 2021 · 8 comments
Open
Labels

Comments

@pooriajr
Copy link

pooriajr commented May 8, 2021

Love the plugin! I've been trying to fix this one little nuisance but no luck.
If I run:

:SoftPencil
:NoPencil
:SoftPencil

Then j and k no longer perform like gj and jk. And even typing gj and gk directly doesn't work like normal - they just work like j and k.

Same thing with $ and 0. Any ideas?

@alerque
Copy link
Member

alerque commented May 8, 2021

Thanks for the report. I've actually run into this myself but never managed to track down what is causing it even as far as you have. I don't have the bandwidth to sit and mess with it right now, but if anybody does have ideas and finds this a PR would be welcome!

I don't typically turn Pencil on or off except once based on the file type on open so this is rare, but I have noted that g prefixed motions are occasionally getting screwed up.

@alerque alerque added the bug label May 8, 2021
@pooriajr
Copy link
Author

pooriajr commented May 8, 2021

No worries!

For me, the use case is that I want to have a "Prose Mode" in vim that is tied to when I enter/leave the Goyo mode from goyo.vim

And when using Goyo, there are a lot of reasons to switch in and out, so Pencil was getting toggled a lot.

For anyone else who might be wanting to do the same, my solution was to drop pencil and manually set up/tear down the mappings and settings I want, like so:

function! StartProse()
  setlocal linebreak
  setlocal wrap
  nnoremap <buffer> j gj
  nnoremap <buffer> k gk
  inoremap <buffer> . .<c-g>u
  inoremap <buffer> ! !<c-g>u
  inoremap <buffer> ? ?<c-g>u
  inoremap <buffer> , ,<c-g>u
  inoremap <buffer> ; ;<c-g>u
  inoremap <buffer> : :<c-g>u
endfunction

function! StopProse()
  setlocal nolinebreak
  setlocal nowrap
  unmap <buffer> j
  unmap <buffer> k
  iunmap <buffer> .
  iunmap <buffer> !
  iunmap <buffer> ?
  iunmap <buffer> ,
  iunmap <buffer> ;
  iunmap <buffer> :
endfunction

autocmd! User GoyoEnter nested call StartProse()
autocmd! User GoyoLeave nested call StopProse()

@evantravers
Copy link

I have always had this problem as well. The only nuance I have:

If you enter pencil mode :PencilSoft and then leave :PencilOff… if you enter it again :PencilSoft the mappings are broken… if you leave the second time and re-enter a third time… the mappings are restored!

It's always alternate… the solution has been for me to quickly "restart" it, but I've never been able to track down why the mappings break the second time.

@charlescochran
Copy link

Facing this issue as well.

@evantravers
Copy link

I wound up doing the same as @pooriajr: https://github.com/evantravers/dotfiles/blob/4cb528afb37a1e87fcbd71ce75a91d1c02de3eef/nvim/.config/nvim/init.lua#L532-L579

I've been using that happily without vim-pencil for quite a while now.

It doesn't have the smart "autodetect what kind of line" stuff that vim-pencil has, but it also doesn't have this bug.

@charlescochran
Copy link

Yeah, I may do this as well. But hopefully this can be fixed at some point, because it's pretty crippling for soft-wrap users.

@Expressive-Synapse
Copy link

as a soft-wrap fan this bug is pretty problematic for me. hopefully some sort of solution can be found.

@charlescochran
Copy link

Funnily enough, this bug drove me (like others) to give up on vim-pencil and make my own Lua-based config. But then I convinced myself to go back to automatic hard-wrapping because I want my markdown files to be viewable in any format. But I decided to stick with a custom config anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants