Open zardoy opened 1 year ago
It looks better than the current solution, I'll try this implementation later.
Hi, @zardoy I finished this implementation at e0d6702, if you'd like to have a try, your feedback is welcome. It's a little stuck when I repeatedly edit a file larger than 10000 lines, and I don't know if it's acceptable with low computing resources.
I don't like the idea of touching the undo stack, this might also interfere with other extensions that watch for changes (eg. vim) and maintain their own undo stack.
I don't like the idea of touching the undo stack, this might also interfere with other extensions that watch for changes (eg. vim) and maintain their own undo stack.
Is undo history necessary if the file is read-only?
Initially, I think I misunderstood your question, so I didn't reply.
Obviously, the undo history is not necessary for a read-only file, in the sense that there will be nothing to undo. But what I think you mean is something like "Why does it matter that the undo stack is modified if the file is read-only?".
I don't know if you've spent any time with one of the vim-like extensions but when it comes to the undo stack they tend to be a bit buggy (it's why I stopped using vscodevim.vim
and eventually started using asvetliakov.vscode-neovim
). The point being is sometimes when extensions start messing with the undo history it can get into a weird state where the undo stack doesn't represent the actual history of changes.
Perhaps I'm being over cautious and I realise we need to work with what we've got but allowing a change then automatically undo-ing it raises alarms in my head as a hack that could break easily with race conditions.
That said, it might just work really well /shrug and I should be less picky. I did spend some time looking for alternatives but again unfortunately I find the extension API (or my imagination) to be lacking.
Hi, gonna be honest, didn't check, but my friend recommended it. I'll just attach the code: