On Tue, May 25, 2010 at 2:27 PM, Nikolai Weibull <[email protected]> wrote:

> I figured that “That said, I think persistent undo is more or less
> useless and, well, just a big pile of potential problems.  Persistent
> undo is in the version control system, not in the editor.” is me
> stating an opinion about it, not saying “please remove it”.

[...]

>
> I gave what I considered to be the deeper solution to a problem that
> one user figured that persistent undo would bring and that was to keep
> edits local.  That someone chose to only focus on the fact that I said
> that I thought persistent undo was a non-solution was where it
> started.

[...]

> Strawman, much?  “I think persistent undo is more or less useless” is
> what I initially wrote, followed by “persistent undo is in the
> version control system, not in the editor”, which I figured would
> imply that my point was that persistent undo is the wrong solution to
> the problem.


Responding to give another perspective on where persistent undo might fit
relative to all of the ways we have to keep track of the history of things.

I think that persistent undo is an excellent *complement* to version
control. It is not a replacement. I use git to manage revisions and history
of every project I work on these days, yet persistent undo is still a great
boon to my productivity.


For example, pretend you're developing the ultimate novel Vim feature, but
you've caused a bug, and want to trace it in gdb. You edit Vim's makefile to
enable -g in CFLAGS, recompile, track down the bug, and want to compile a
release version. I wouldn't have committed enabling -g in git, as it's a
transient change that I don't want to make permanent. So I edit again and
undo the change.

As another example, pretend you're editing your Apache config in an attempt
to get a new module working on your web page. The workflow here is a tight
loop - edit, reload apache, test, repeat. If it's too much overhead in this
tight loop to continue committing small changes to git, then it's no problem
to undo the failed couple lines of new configuration and try again.


Persistent undo is a good complement to revision control because it fills in
a lower 'tier' of persistence, between session-limited undos and revision
control. I think of this space as the realm of small, experimental changes,
but of course that is open to the interpretation that works best with the
user's workflow. And of course, as others have mentioned, it is an optional
feature, so the user may choose to ignore it as she wishes.


- Jordan

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Raspunde prin e-mail lui