Visual Studio : exclude outlining from undo/redo stack

Question

There\'s something really annoying in Visual Studio : when I expand or collapse a method or code region, this action is pushed on the undo stack. So if I edit some code in a met

Answer 1

I did a little poking around and discovered that there is in fact an option in Visual Studio to disable this behavior, and yet it does not seem to be exposed anywhere in the user interface. However, you can set it programmatically, and I tested that it does work, so it is (technically) possible.

The options is:

DefaultTextViewOptions.OutliningUndoOptionId

and you set it like this:

textView.Options.SetOptionValue(DefaultTextViewOptions.OutliningUndoOptionId, false);

With this information a very simple Visual Studio extension could be written to toggle this setting for all new ITextView instances.

Answer 2

You can vote for fixing it in Visual Studio UserVoice.

Answer 3

The best solution I can propose is to disable outlining using CTRL+M, then CTRL+P.

Answer 4

I've created the Disable Outlining Undo extension that excludes expanding and collapsing operations from recording to the undo/redo stack in Visual Studio 2017/2019.

Thanks to Rick Sladkey for the idea!

Answer 5

First, it seems that not all outlining operations are recorded in the undo/redo stack.

• Toggle Outlining Expansion (CTRL+M/CTRL+M) is recorded in the stack
• Toggle All Outlining (CTRL+M/CTRL+L) is recorded in the stack
• Collapse to definitions (CTRL+M/CTRL+O) is NOT recorded in the stack

So, as far as I know, it is not possible to avoid the recording of Toggle operations in the undo/redo stack in Visual Studio 2008.

The only option you have it to enable/disable outlining for each source type. For C#, outlining can be enabled/disabled in Tools → Options → Text Editor → C# → Advanced with the Enter outlining mode when files open checkbox.

Answer 6

I don't believe there is a way to disable this behavior.

As alternatives, the undo and redo toolbar icons have history dropdowns that allow you to visually see a summary of what the recent changes were that you would be undoing or redoing. That can sometimes help to ensure you're undoing (or redoing) what you're expecting.

Since that isn't always enough to know exactly what the changes are (the undo history only displays a summary), the solution I occasionally use to address this is to combine undo (ctrl-z), redo (ctrl-y), and undo again. The first undo moves to where the change happened (and undoes that change). The redo will undo the undo (which essentially repeats the last change made). And the last undo will perform the undo again with the window scrolled to the location where I can actually see the undo happening and can confirm whether that's the change I was expecting to undo. It's not very efficient, but it can be very effective to ensure the code is in state that's really expected.