gerardroche
commented
7 years ago Open gerardroche opened 7 years ago
gerardroche
commented
7 years ago gerardroche
commented
7 years ago 
So how did that diff improve the behavior of redo? I'm seeing the same behavior, I believe.
gerardroche
commented
7 years ago
Specifically, Vim leaves the cursor at the start of the "redone" change - not the end of it.
gerardroche
commented
7 years ago 
Oh, yeah, it's simply restoring the caret position before the redo op. It should find the start of the edit instead.
gerardroche
commented
7 years ago gerardroche
commented
7 years ago
Which doesn't seem to be too simple, though... :/
gerardroche
commented
7 years ago
Any thoughts on this? I think it's the last thing holding me back from switching full-on to Vintageous. Haven't you ever noticed that sometimes it's impossible to undo/redo/undo/redo to see a particular change that you made? This is the culprit, I believe.
One challenge is that Sublime's undo/redo gets this wrong itself so Vintageous will need to improve upon it. Every item on the undo/redo stack might need to have the original cursor position recorded if it can't be inferred from the change data itself.
gerardroche
commented
7 years ago
Doesn't seem to bother me so much, but I'd like to get this right in Vintageous as a main goal. However, I indeed suspect Sublime Text can't provide the means to make this work, and although I have a couple of ideas, I'm not confident they will work.
Anyhow, it'll be some time before I revisit this issue.
gerardroche
commented
7 years ago
I really wish we had a fix for this - I know I keep saying it, but this has got to be the last thing that keeps me from switching completely.
The reason why I feel it is so bad, is that there are situations you can get into, where it is impossible to tell which changes you are redoing and undoing - it jumps around the screen and "skips over" changes. In Vim you can always go u->c-r to reply any change, regardless of how the two subsequent changes are spread out over the file.
gerardroche
commented
7 years ago
I haven't thought the issue through, but it seems it's impossible to hook into the undo stack's .push() method, so it isn't possible to know when an editing command has been run by the user. Without that information, I don't think Vintageous can track the cursor location reliably.
Probably inspecting the command history and comparing the oldest known item to the newest would help, but I haven't explored that option.
gerardroche
commented
7 years ago
S3 commits selection changes as well as buffer edits to the command history, but does not provide any way to distinguish between the two.
To improve the cursor placement in Vintageous when undoing/redoing, it should suffice to know the current index into the command history and whether the recorded command at that position is a modifying command or not.
Until that's available through the api, I've run out of ideas to solve this issue.
gerardroche
commented
7 years ago
Do you think the main Sublime author will be supportive of implementing this? I would think he'd be supportive because Vintageous is the best Vim mode effort for Sublime and by having a solid Vim mode in Sublime, many users will likely convert.
gerardroche
commented
7 years ago
I hope so, but I suppose it won't be a priority for them. Perhaps too narrow of a scope for practical usage.
gerardroche
commented
7 years ago
Actually, I believe their current experience is horribly broken even outside of Vintageous - so I hope they'd like to fix it regardless.
gerardroche
commented
7 years ago
I have to say, this is really inhibiting my productivity. Honestly, everything about using sublime with Vintegeous is spot on except this. Is it possible to record the position when beginning insert mode (or delete/change command) in Vintageous - and then remap (c-r) to not only redo as normal, but then jump to that previously recorded location? We're so close here!
gerardroche
commented
7 years ago
I'll think about it. We'll get it right eventually.
gerardroche
commented
7 years ago
Related: http://www.sublimetext.com/forum/viewtopic.php?f=3&t=9802
gerardroche
commented
7 years ago
And I just realized that vintageous reimplements redo/undo in a different way than the standard sublime undo/redo. Both are broken. Have you considered implementing your own undo/redo? You'd probably want an undo tree, instead of an undo stack (vim has an undo tree and it unleashes all kinds of awesome plugin opportunities).
gerardroche
commented
7 years ago
Maybe we can evaluate this plugin: https://github.com/randy3k/ChangeList
gerardroche
commented
7 years ago
I brought up the issue here: https://github.com/SublimeText/Issues/issues/107
@guillermooo: This isn't a bug in your code by any means, but do you have any suggestions about how to fix this, whether or not SublimeHQ does? It totally ruins the Vim feel (even if it's not your fault).
gerardroche
commented
7 years ago
@jordwalke Too much work for me at the moment. I'm all for improving undo/redo, but I think it'd be wise to wait and see ST's next move. Also, I'm in the middle of another big refactor to simplify handling of commands internally, so that'll keep me busy for some time.
Do you have repro steps, BTW?
gerardroche
commented
7 years ago
I mention the repro steps here:
https://github.com/SublimeText/Issues/issues/107#issuecomment-21991912
Maybe if I put a 100$ bounty on it? :) It's not a problem with Vintageous, it's a problem with Sublime. But since it effects the "vim feel", it might have to be fixed at the Vintageous level.
gerardroche
commented
7 years ago
I don't think I'd be able to deliver :) There's too many open questions regarding undo/redo/macros. Either Vintageous or ST or both are too brittle with regards to this.
I guess Vintageous could intercept all commands via .on_text_command() and decide whether to keep them in its own history or discard them, but I'd rather ST had a .on_add_to_history() providing details on selections, command name, params... Also, ST command history should probably be editable and expose some internal data.
I think I'll first work on other existing bugs, then on the ex mode in 4.0 and maybe later on this. By that time, ST 3.0 final should be out and perhaps this particular problem will have a more obvious solution.
As far as I'm concerned, getting this and caret placement right are top priorities, but I don't see how to make them happen in a satisfactory way.
gerardroche
commented
7 years ago
I don't blame you. It seems we must rely solely on the Sublime developer to fix this issue. But I have never seen him respond to this bug which has been brought up by several people. I sure hope Sublime hasn't got into unsupported mode.
gerardroche
commented
7 years ago
The worst part about this is that there is no consistency. Wherever you are in the undo stack, if you move your cursor - that becomes your new cursor position every time you undo/redo to that save point. Again, I know this isn't Vintageous' fault.
gerardroche
commented
7 years ago
So I realized that there's actually two issues. Redo should leave cursor at the beginning of the redone change, but that's not as serious as the second issue.
The second issue is that Sublime associates a cursor position with each place in the undo tree. If you undo to a version, then move your cursor, whatever you do - if you undo/redo and end up on that version in the undo tree again at some point, it will force your cursor to where you left it the last time you were at that version. This is the main issue - and the main reason why it's easy to get in a situation where it is impossible to see what changes have been applied by replaying redo.
I asked a bunch of Sublime users how this doesn't disturb them to the point of insanity. Everyone that said they didn't notice it, doesn't use Vintageous. The reason is because the way you navigate code in a Vim mode, is by moving the cursor so you are very likely to get in this situation. People who don't use Vim modes scroll to where they want to move (with a mouse) and so they don't notice it. I think this is a hugely critical issue, but now that I've articulated the exact problem well, I feel it's easier to fix. I even started hacking together a solution but I don't know Sublime's API as well as you (or Python for that matter). (I actually made good progress but noticed inconsistencies in sublime's API).
Wouldn't it be possible to simply compare the file text before and after a redo/undo and move the cursor to the first character sequence that differs between the two versions (also clearing out any selections - as vim always does when you undo/redo/repeat)?
gerardroche
commented
7 years ago
I don't know if there's a bot that will post here eventually, but linking to the bounty just in case it doesn't: https://www.bountysource.com/issues/798485-redo-should-leave-cursor-at-the-beginning-of-the-redone-edit
gerardroche
commented
7 years ago gerardroche
commented
6 years ago I think this has been fixed. At least I think it now works the same in NeoVintageous as it does in Sublime Text.
Sublime still puts the cursor at the end of the redo text, which I agree can be disorienting.
I asked a bunch of Sublime users how this doesn't disturb them to the point of insanity. Everyone that said they didn't notice it, doesn't use Vintageous. The reason is because the way you navigate code in a Vim mode, is by moving the cursor so you are very likely to get in this situation. People who don't use Vim modes scroll to where they want to move (with a mouse) and so they don't notice it.
They also don't notice it because they have no reference point for how good they could have it.
The more you use Vim the more you start to feel how so very good it is at all the small things. Then when you switch back to other editors they start to niggle at you at every turn.
Sheepolution
commented
5 years ago @gerardroche Please re-open this issue.
In the gif below I did the following:
On the 3rd undo it restores the deleted word at the bottom, and then jumps to the top, without restoring the deleted word at the top. Redo brings you back down, and deletes the word, undo brings you back up again, without being able to see what change was done at the bottom.
Next I do the following:
The jumping behaviour is now normal. What's interesting is that if you first use Neovintageous to undo/redo, and after that use Sublime's undo/redo, you will also get the weird jumping behaviour with sublime. So by undoing/redoing using Neovintageous you seem to mess up the undo/redo data.
Sheepolution
commented
5 years ago I realized that since the Sublime Text's default works fine, this can be easily solved by doing the following mapping:
nnoremap u :Undo<CR>
nnoremap U :Redo<CR>But then I think this should be the default, unless I'm missing something?
gerardroche
commented
5 years ago How are you running the redo command, it looks like you don't have the ctrl keys enabled?
To enable ctrl keys Menu > Preferences > Settings
{
"vintageous_use_ctrl_keys": true
}When the ctrl keys are enabled everything works as expected using u to undo and ctrl-r to redo.
It looks like the issue with the way mappings are processed or run, so though <C-r> will work as expected when run directly with ctrl keys enabled, it runs slightly differently when mapped:
nnoremap <leader>r <C-r>But mapping directly to the Sublime Command works as expected:
nnoremap <leader>r :Redo<CR>So it looks like the issue is the way the mapping is handled. My guess is that the mapping commands are being run through a Sublime Text WindowCommand oppose to being wrapped in a TextCommand. I recall some similar issues in Sublime and running the commands through a TextCommand fixed the issue.
Vim leaves the cursor at the beginning of the redone edit. This is critical for being able to correctly reply changes through a file and visually determine what is changing.