scrolloff is not reverted back to its old value on exiting

[jmlucjav]

Hi,

I have

scrolloff=999

but after a while, I notice it is set to 0. I have searched over all my plugins etc, and lightspeed is a suspect. I saw this #27 and it look related. I understand this should be temporary, but it seems something is not ok and scrolloff stays at 0.

Is there anything I could do to verify this?

thanks

[ggandor]

Hi! Yes, I suspect we are the guilty ones. It should be temporary of course, any exit form (those are macros handling cleanup stuff) triggers autocommands that restore these editor options unconditionally - the only possible explanation is that somehow I've missed a possible return point (the flow is indeed quite complicated in sx.) I'll look into this ASAP.

In the meanwhile, it would be great if you could help me narrow it down, when exactly does this occur? (Successful jump or early exit, e.g. C-c-ing? Using a shortcut? After switching match groups? Etc.)

[jmlucjav]

Hi,

I am trying to narrow it down but for now I could not repro it.

FYI, in case it helps, I have these in my init.vim:

" lightspeed ----------------------------------------------------------- 
"make native ;/,; for f/t next
fun! s:RepeatFt(reverse)
  lua require'lightspeed'.ft['instant-repeat?'] = true
  lua require'lightspeed'.ft:to(vim.api.nvim_eval('a:reverse'),require'lightspeed'.ft['prev-t-like?'])
endfun
nnoremap <silent> ; <cmd>call <SID>RepeatFt(v:false)<cr>
xnoremap <silent> ; <cmd>call <SID>RepeatFt(v:false)<cr>
nnoremap <silent> <leader>;  <cmd>call <SID>RepeatFt(v:true)<cr>
xnoremap <silent> <leader>; <cmd>call <SID>RepeatFt(v:true)<cr>

[ggandor]

Hmm, it's great that you shared the config - it seems you're using a pretty old version, this workaround is not valid anymore, we have <Plug> keys for ;/, now. Would you test if the issue still persists using the most recent commit? Because I fixed a relevant issue recently, I'm 99% sure that is the one we're looking for.

EDIT: First let's make sure that the bug indeed occurs with f/t + operations only, if it does, then I think we're done, the update will solve the problem.

[jmlucjav]

version is about a couple of months or so I guess, but yeah, I just updated, and will ping here if I see the issue again in the following days.

Thanks!

[ggandor]

I'm closing this now, we can reopen anytime if needed.

[gimerstedt]

ah, this is what's causing my scrolloff to change. i am getting this with 3140e02 so i assume this is still an issue.

[ggandor]

ah, this is what's causing my scrolloff to change. i am getting this with 3140e02 so i assume this is still an issue.

Okay, then the task is the same as before: try to narrow it down, if you're able to, because now I really have no idea offhand where the potential "leak" could be.

[gimerstedt]

had the same experience as @jmlucjav and was unable to replicate it when trying, so i have no idea what it could be. i have not experienced it before and the only thing added was this plugin (since removed due to wontfixes) so i'm 99% certain it was caused by it. best of luck.

[ggandor]

A note for everyone experiencing this issue: the problem can be circumvented by "manually" setting the value back to the preferred one, hardcoded into an autocommand, on exiting Lightspeed.

Caveat: you should define this autocommand after Lightspeed has been sourced, else Lightspeed's one will overwrite yours (:h au).

" + the usual augroup boilerplate
autocmd User LightspeedLeave set scrolloff=...