Skip to content

change diff update to whole buffer #116

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

Merged
merged 1 commit into from
Nov 16, 2023
Merged

change diff update to whole buffer #116

merged 1 commit into from
Nov 16, 2023

Conversation

glepnir
Copy link
Member

@glepnir glepnir commented Oct 17, 2023

diff update has bug .back to update whole buffer

@xiaoshihou514
Copy link
Collaborator

xiaoshihou514 commented Oct 17, 2023

Eliminate update bugs caused by calculating the buffer area

Is apply_text_edit thread safe or sth?

@glepnir glepnir force-pushed the new_update branch 2 times, most recently from d97debb to 5d60930 Compare October 17, 2023 11:37
@glepnir glepnir changed the title improve: use apply text edits update range change diff update to whole buffer Oct 17, 2023
@glepnir
Copy link
Member Author

glepnir commented Oct 17, 2023

nope. just a try. diff update has bug. now back to update whole buffer if has result .

@xiaoshihou514
Copy link
Collaborator

xiaoshihou514 commented Oct 17, 2023

    1. Any idea why🤔?
    1. lsp.util.apply_text_edit doesn't fix this?
    1. How can I repro this? I would like to help

@glepnir
Copy link
Member Author

glepnir commented Oct 17, 2023

diff return data like 240, 0, 241, 1 of start_a, start_a, start_b, count_b Didn't understand the rules. Causes buffer confusion after update. So first go back and update the entire buffer. I think a benchmark is needed here. Because we need to know whether using diff is worth it. The time to update the entire buffer and the time to run the diff algorithm. It should be possible to benchmark large files

@glepnir
Copy link
Member Author

glepnir commented Oct 17, 2023

not sure. I remember this code will cause a format bug.

local t = {}

function t.a()
end

function t.b()
end

return t

@xiaoshihou514
Copy link
Collaborator

xiaoshihou514 commented Nov 2, 2023

Some limited benchmarking:
https://github.com/xiaoshihou514/guard-bench
Tested by manually toggling update methods and nvim -u init.lua

  • All files have the spaces changed to 8 spaces, in this case diffing is about 25% percent slower on average
    (diff 8ms, no diff 6ms with big.js)

  • All files have " = " changed to "=", in this case diffing does better, but still does worse than not diffing
    (diff 7ms, no diff 6ms with big.js)

Someone may be interested to do more rigorous and automated benchmarking to find the overall balance, but at this point I think there is really no point perfing the update method. big.js is 10k LOC, which is about what you can get when writing serious code, but updating buffer only takes less than 10ms, and the difference made by diffing is even smaller, I argue this is negligible compared to the heavy lifting done by the formatter itself. Under all circumstances, diffing or not does not really change the user experience in terms of formatting speed. And if diffing the buffer contents causes bug from time to time, I would call for its removal.

edit: not sure about mem usage tho

@xiaoshihou514
Copy link
Collaborator

@glepnir mergable yet?

@xiaoshihou514 xiaoshihou514 merged commit f4438af into main Nov 16, 2023
@xiaoshihou514 xiaoshihou514 deleted the new_update branch December 7, 2024 11:43
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

Successfully merging this pull request may close these issues.

2 participants