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

async Mode chopping off 1st Char on Write #2

Closed
Nealium opened this issue Apr 18, 2022 · 2 comments
Closed

async Mode chopping off 1st Char on Write #2

Nealium opened this issue Apr 18, 2022 · 2 comments

Comments

@Nealium
Copy link
Owner

Nealium commented Apr 18, 2022

Issue description

Saving an edit sometimes chops of the first character in the showed ~7 lines rendered on the __CtrlSF__ Buffer

Things about your system and environment(请在此填写你的系统信息)

field value
os Windows 10 Pro 21H1
vim Vim 8.2 Included patches: 1-12
backend ag 2.2.5
locale C.UTF-8

vimrc:

" CtrlSF
" let g:ctrlsf_debug_mode = 1
"   Maps -> Ctrl+F . Letter
nmap     <C-F>f <Plug>CtrlSFPrompt
vmap     <C-F>f <Plug>CtrlSFVwordPath
vmap     <C-F>F <Plug>CtrlSFVwordExec
nmap     <C-F>n <Plug>CtrlSFCwordPath
nmap     <C-F>p <Plug>CtrlSFPwordPath
nnoremap <C-F>o :CtrlSFOpen<CR>
nnoremap <C-F>t :CtrlSFToggle<CR>
inoremap <C-F>t <Esc>:CtrlSFToggle<CR>

"   Default Regex on
let g:ctrlsf_regex_pattern = 1
"   Don't be hangin
let g:ctrlsf_search_mode = 'async'

file:

  • Any File, no consistency
@Nealium
Copy link
Owner Author

Nealium commented Apr 18, 2022

async specific.

Reason:

  • __CtrlSF__'s Indent changes at some point during a very long search.
    • I was able to repeatably recreate this with a search that returned 300+ Files
      • specifically an Include Password in a PHP project
    • The point where it changed wasn't consistent, but it always changed
  • This was due to ctrlsf#db#MaxLnum() changing due to a new match coming in with a larger Line Number
  • The previously rendered Matches were not updated with the new indent, but on Write it took the MaxLine of the entire Buffer- hence, the root of the problem.

Solution:

  • Give each Paragraph it's own Max Line Attribute and use that on NormalViewIncr + Unrender instead of the per-search

@Nealium
Copy link
Owner Author

Nealium commented Apr 18, 2022

I big downside of this solution is that if a page has multiple matches / paragraphs, they'll have different indents, which might look confusing.

Two potential solutions:

  1. Set mlnum to a hard var, and update all paragraphs for a page when a new max is found
  2. add mlnum to file object, and loop everything through files instead of a paragraphs
    • Max Line could be hard or just a page.para[-1].lines[-1].lnum
    • This would be a radical change to how it's rendered and unrendered

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

No branches or pull requests

1 participant