1 Reply by sticks

  • sticks
  • Member
  • Offline
  • Registered: 2006-02-09
  • Posts: 19

Re: undo too greedy

There's a change in behavior that I don't particularly like and would consider a bug, (but I don't know if it was done to faithfully mimic vim.)

Basically, the undo buffer isn't breaking when i use non-vi controls to move around the file. So if I do some editing in insert mode, then use the mouse (or arrow keys, I think,) and then go type something else some where else, (still in insert mode,) then an "undo" undoes both of these inserts. I'm pretty sure it didn't used to do that and I am certain that it confuses the hell out me now. smile

I remember reading on here that you were intentionally going to make the undo group stuff up to get rid of the one-character-at-a-time undo, but I think that this goes too far.

So would this be a bug or intended and if it is intended, can I have an option to turn it off and make an undo step stop at movement of the cursor through non-vi controls? To be honest, I find the one-character stuff more reasonable.

thanks, nathan

2 Reply by Jon_Symnum

  • Jon_Symnum
  • Administrator
  • Offline
  • Registered: 2006-01-20
  • Posts: 1,658

Re: undo too greedy

Nathan,

You're right, currently, ViEmu 2.x inserts markers in the undo queue with its own idea of what constitutes an 'undo separator', modeled after vim. Something that may work would be to insert extra markers when "external changes" are detected, such as moving the cursor somewhere else. This should make it simpler. I will try to implement something like this in a future version.

Meanwhile, since ViEmu doesn't break Visual Studio's undo, you could use the following maps:

  nnoremap u :vsc Edit.Undo<return>
  nnoremap <c-r> :vsc Edit.Undo<return>

The only problem will be that the markers themselves are necessarily undoable actions, even if they actually do nothing to the buffer, so they will require an undo for this. Removing them too would make it more understandable.

In any case, I will take note of this for one of the next versions of ViEmu.

Thanks,

  Jon

3 Reply by timaki

  • timaki
  • Member
  • Offline
  • Registered: 2006-10-18
  • Posts: 9

Re: undo too greedy

Here is one area where there needs to be an undo marker placed in the queue: after every search/replace operation using Visual Studio's Replace dialog. I'm upgrading an application from VB6 to .NET, and I'm doing a lot of search-and-replace operations within each file. The problem is that if I do, say, ten search-and-replace updates, but mistype the replacement string in the last one, I will (without thinking) hit the 'u' key to undo the last change. Unfortunately, this undoes all ten replacements, and I have to start all over.

4 Reply by Jon_Symnum

  • Jon_Symnum
  • Administrator
  • Offline
  • Registered: 2006-01-20
  • Posts: 1,658

Re: undo too greedy

timaki, if you want to undo actions "VS-wise", that is, without using ViEmu's grouping, you can just use Visual Studio's own "Undo" by using Ctrl-Z, Edit->Undo, or the undo icon in the toolbar. Hopefully that is enough?

Adding markers to external actions may cause some other problems, so I think the best would be to use this workaround. Please let me know if it's not enough so that I think about some possible fix.

Thanks and best regards,

  Jon

5 Reply by kroiz

  • kroiz
  • Member
  • Offline
  • Registered: 2006-11-21
  • Posts: 34

Re: undo too greedy

Jon wrote:

The only problem will be that the markers themselves are necessarily undoable actions, even if they actually do nothing to the buffer, so they will require an undo for this. Removing them too would make it more understandable.

Would you please explain this. I did not get it. what is wrong with this workaround?

Last edited by kroiz (2006-11-22 13:40:59)

6 Reply by Jon_Symnum

  • Jon_Symnum
  • Administrator
  • Offline
  • Registered: 2006-01-20
  • Posts: 1,658

Re: undo too greedy

Hi kroiz,

Indeed. ViEmu 1.x used Visual Studio's internal system to group several actions into a single undo-queue action. The goal was that, if you use 'cwHello<esc>' or '2p', which perform several operations. VS's internal system has quite a few limitations, which prevented me from keeping an "open undo group" while in insert mode (syntax highlighting in several of VS's languages would stop working meanwhile, etc...). So ViEmu 1.x only grouped operations such as '2p' or '3x', etc...

Starting with ViEmu 2.0, I stopped using Visual Studio's internal system. I implemented a new system based on inserting dummy operations in VS's undo queue. If you open the undo queue while using ViEmu, you will see some actions listed as '---'. This operations are actually no-ops, that is, undoing and redoing them doesn't actually do anything, but they are looked for by ViEmu's implementation of undo and redo ('u' and '^r' commands). This system allows outstanding groups in insert mode (because they are not actual 'groups'), and thus ViEmu 2.0 is much more similar to vim in its undo grouping behavior.

The problem is that nathan ('sticks') pointed out above that the new system includes all VS-initiated actions (a VS search and replace, or VS's 'comment', 'uppercase', etc... operations) in the last open ViEmu group, thus, a 'u' may undo one ViEmu action PLUS several VS actions on a row.

I acknowledged the misbehavior, which I plan to fix in a future revision, but I also suggested a temporary workaround: use VS's Ctrl-Z to undo, which will undo single, atomic, non-grouped actions. The only problem with this workaround is that the dummy marker-action ('---') is also an action in VS's understanding, and thus there will be one extra Ctrl-Z needed which won't actually undo any real operation.

The proper fix, which I plan to implement in a later release, would be to sense 'external' (non-ViEmu) operations in the buffer, and insert extra markers, so that u/^R will treat these 'external' operations as separate from the nearest ViEmu operations.

Best regards,

  Jon