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 chops off first character when editing many files #329

Open
Nealium opened this issue Jul 18, 2022 · 1 comment
Open

async chops off first character when editing many files #329

Nealium opened this issue Jul 18, 2022 · 1 comment

Comments

@Nealium
Copy link

Nealium commented Jul 18, 2022

Issue description

Saving an edit with async mode sometimes chops of the first character.

Happens when searching entire moderately sized projects and editing many files.
Examples: updating Javascript Versions in HTML files or includes in PHP Files
See the How to Recreate section

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'
  • Log:
    No Logs

How to Recreate:

  • Create an Empty Folder and Run this Shell Script in it (Replicating project size)
    • End might need to be tweaked if you've got a super PC, async needs to render results in multiple batches.
    • File type doesn't matter, but php/html shows the issue well
#!/bin/sh

TEXT="<?php\n<!DOCTYPE html>\n<meta charset=\"utf-8\">\n<html lang=\"en\">\n<head>\n<title>Test</title>\n</head>\n?>"

START=1
END=55

for (( c=$START; c<=$END; c++ ))
do
  echo -e $TEXT > ${c}_tmp.php
done

((END=END+1))

ENDTEXT="<?php\n<!DOCTYPE html>\n<meta charset=\"utf-8\">\n<html lang=\"en\">\n<head>\n<title>Last</title>\n</head>\n<head>\n\t<div class=\"nav\">\n\t\t<h1>ctrlsf bug Example</h1>\n\t</div>\n\t<hr>\n\t<div class=\"contents\">\n\t\t<p>\n\t\t\tSomewhere above this results the tab amount will change from 4 to 5.\n\t\t\tSearch: \"Test\"\n\t\t</p>\n\t</div>\n</head>\n?>"
echo -e $ENDTEXT > ${END}_tmp.php
  • Search the files in the folder using this: CTRLSF Test -filetype php

  • Before continuing, search 5 spaces in the results buffer

    • This will show you the underlying issue / reason
    • Note: All files but the last are the same
  • Edit using: %s/Test/test/ + Save&Write

  • Re-Search using: CTRLSF test -filetype php

    • Higher up results should be missing the first character
    • if not: increase END
Before Edit
<?php
<!DOCTYPE html>
<meta charset="utf-8">
<html lang="en">
<head>
<title>Test</title>
</head>
?>
After Edit
<?php
<!DOCTYPE html>
meta charset="utf-8">
html lang="en">
head>
title>test</title>
/head>
>
Note: rerunning the Shell Script resets files to the original (Good for debugging!)

Reason:

  • Due to ctrlsf#db#MaxLnum() changing mid-search + not updating already rendered matches
    • Generates x results, with max length 7, rendering with the default 4 spaces.
    • Suddenly finds result with max length 19, uses 5 spaces to render it and any result found after.
    • On write, uses the max length 19, ignoring 5 spaces for write, which excludes the first char from the results rendered using 4 spaces.

My Solution:

  • I made a fork and fixed it for myself, I kept hitting this issue + breaking prod
  • I gave each Paragraph their own Max Line attribute and used that to render+save
    • This solution is iffy, as files with two paragraphs could have different tabs, could be confusing (I haven't even noticed it though)
    • I pondered adding the Max Line to the File Obj, but that seemed like a lot of work as rendering+saving is built around Paragraphs
  • It took me a while to make an issue because I knew I would have to figure out a way to accurately recreate it
@dyng
Copy link
Owner

dyng commented Jul 20, 2022

Thank you for so comprehensive issue along with the root cause you found! I prefer the second approach but as you said it's a fundamental change.

anhpt379 added a commit to anhpt379/dotfiles that referenced this issue Nov 30, 2022
It has been fixed in
Nealium/ctrlsf.vim@87b1196,
but it's not in upstream yet. For now, let's just fallback to `sync`
search mode.

dyng/ctrlsf.vim#329
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

2 participants