Update on Vim 7.3 status
Bram Moolenaar
As you may have noticed, I have added the persistent undo patch
yesterday. The core of this was done by Jordan Lewis.
This means you can make changes to a file, quit Vim, edit that same file
and undo the previous changes.
I have added a few things, such as computing a hash of the text to
verify it is equal to when the undo file was written. That works better
than a timestamp.
I also changed it to put the undofile with the edited file. That should
work, as writing a file usually means the undofile can be written there
as well. It's possible to change this with the 'undodir' option.
Note that despite the checks it might still be possible that the undo
information is corruped and changes your text in unexpected ways. Be
careful.
I have also changed the MS-Windows installer. It should now work in
Windows 7. I also tried making the "Edit with Vim" context menu work
for 64 bit systems, but it doesn't appear to work yet.
You can try the self-installing executable:
ftp://ftp.vim.org/pub/vim/unstable/gvim73a.exe
This is just a snapshot, I won't keep this updated.
I used a different compiler, the MSVC 2010 Express version, but it
doesn't look like that changed anything.
--
From "know your smileys":
@:-() Elvis Presley
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
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
Nico
> I have also changed the MS-Windows installer. It should now work in
> Windows 7. I also tried making the "Edit with Vim" context menu work
> for 64 bit systems, but it doesn't appear to work yet.
>
> You can try the self-installing executable:
> ftp://ftp.vim.org/pub/vim/unstable/gvim73a.exe
against Python 2.4. I'm assuming whenever the official 7.3 installer
is released it will be against 2.6. If so, could you build the
snapshot against 2.6 as well, whenever the next one is built?
Nico
Jordan Lewis
As you may have noticed, I have added the persistent undo patch
yesterday. The core of this was done by Jordan Lewis.
This means you can make changes to a file, quit Vim, edit that same file
and undo the previous changes.
I have added a few things, such as computing a hash of the text to
verify it is equal to when the undo file was written. That works better
than a timestamp.
I also changed it to put the undofile with the edited file. That should
work, as writing a file usually means the undofile can be written there
as well. It's possible to change this with the 'undodir' option.
Note that despite the checks it might still be possible that the undo
information is corruped and changes your text in unexpected ways. Be
careful.
This is excellent news! Thanks for your work.
I am a bit concerned with your decision to write undo files to the current directory by default, though. I think that it is "impolite" to users to have Vim store its state (especially at the 1-statefile-per-file rate that undo persistence uses) directly in the user's working directory. It makes more sense to me to use an undo directory within ~/.vim by default. If that fails, then the right thing to do would be to go ahead and write in the file's directory since, as you mentioned, it is likely to succeed.
I suppose the argument could be made that the user who has added undo persistence to her vimrc would have read enough of the documentation to know that she must also set undodir if she doesn't want a polluted current working directory. I don't think that this argument is strong enough to warrant using the new default behavior, though, since a less clued-in user might not understand why his working directory is suddenly full of dot files.
- Jordan Lewis
Bram Moolenaar
Nico Raffo wrote:
> On May 24, 1:06=A0pm, Bram Moolenaar <B...@Moolenaar.net> wrote:
> > I have also changed the MS-Windows installer. =A0It should now work in
> > Windows 7. =A0I also tried making the "Edit with Vim" context menu work
> >
> > You can try the self-installing executable:
> Thanks for providing this! It appears that the installer was built
> against Python 2.4. I'm assuming whenever the official 7.3 installer
> is released it will be against 2.6. If so, could you build the
> snapshot against 2.6 as well, whenever the next one is built?
make that work. You can try it yourself, if you like.
I also have a patch to support Python 3. We'll have to see if
dynamically loading both will work. I don't know if anyone tried that.
--
From "know your smileys":
o _ _ _
_o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_ \_| \ _|/' \/
(_)>(_) (_) (_) (_) (_)' _\o_
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Bram Moolenaar
Jordan Lewis wrote:
> --0016e68ee46947c7a104875ce992
> Content-Type: text/plain; charset=ISO-8859-1
> On Mon, May 24, 2010 at 3:06 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> >
> > As you may have noticed, I have added the persistent undo patch
> > yesterday. The core of this was done by Jordan Lewis.
> > This means you can make changes to a file, quit Vim, edit that same file
> > and undo the previous changes.
> >
> > I have added a few things, such as computing a hash of the text to
> > verify it is equal to when the undo file was written. That works better
> > than a timestamp.
> > I also changed it to put the undofile with the edited file. That should
> > work, as writing a file usually means the undofile can be written there
> > as well. It's possible to change this with the 'undodir' option.
> >
> > Note that despite the checks it might still be possible that the undo
> > information is corruped and changes your text in unexpected ways. Be
> > careful.
> >
>
> This is excellent news! Thanks for your work.
>
> I am a bit concerned with your decision to write undo files to the current
> directory by default, though. I think that it is "impolite" to users to have
> Vim store its state (especially at the 1-statefile-per-file rate that undo
> persistence uses) directly in the user's working directory. It makes more
> sense to me to use an undo directory within ~/.vim by default. If that
> fails, then the right thing to do would be to go ahead and write in the
> file's directory since, as you mentioned, it is likely to succeed.
very easy to misplace the undo file. Also, when a file is edited by
several people, or the same person with different login names or from
different systems, the undo file would go in the wrong place. Also
problems with renaming a directory, moving a directory tree, backups,
etc.
> I suppose the argument could be made that the user who has added undo
> persistence to her vimrc would have read enough of the documentation to know
> that she must also set undodir if she doesn't want a polluted current
> working directory. I don't think that this argument is strong enough to
> warrant using the new default behavior, though, since a less clued-in user
> might not understand why his working directory is suddenly full of dot
> files.
with a dot), thus are less intrusive. It's also like swap files, they
also go in the same directory as the file, by default. Still, when a
directory is not writable swap files need to go elsewhere. Undo files
won't be written when a file is not writable.
--
I AM THANKFUL...
...for the taxes that I pay because it means that I am employed.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Tux
I suppose most people will want Python 2.6. I'll see if I manage to make that work. You can try it yourself, if you like.
James Vega
>
> Jordan Lewis wrote:
> > I suppose the argument could be made that the user who has added undo
> > persistence to her vimrc would have read enough of the documentation to know
> > that she must also set undodir if she doesn't want a polluted current
> > working directory. I don't think that this argument is strong enough to
> > warrant using the new default behavior, though, since a less clued-in user
> > might not understand why his working directory is suddenly full of dot
> > files.
>
> It's a bit like using backup files. The undo files are hidden (start
> with a dot), thus are less intrusive. It's also like swap files, they
> also go in the same directory as the file, by default. Still, when a
> directory is not writable swap files need to go elsewhere. Undo files
> won't be written when a file is not writable.
Are the undo files supposed to be hidden when 'undodir' is not the
current directory? If so, that's not currently the case.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>
Tony Mechelynck
[...]
> current directory by default, though. I think that it is "impolite" to
> users to have Vim store its state (especially at the
> 1-statefile-per-file rate that undo persistence uses) directly in the
> user's working directory. It makes more sense to me to use an undo
> directory within ~/.vim by default. If that fails, then the right thing
> to do would be to go ahead and write in the file's directory since, as
> you mentioned, it is likely to succeed.
>
> I suppose the argument could be made that the user who has added undo
> persistence to her vimrc would have read enough of the documentation to
> know that she must also set undodir if she doesn't want a polluted
> current working directory. I don't think that this argument is strong
> enough to warrant using the new default behavior, though, since a less
> clued-in user might not understand why his working directory is suddenly
> full of dot files.
>
>
>
> - Jordan Lewis
:lcd) but the directory of the file. The advantage of this choice is
that you could quite possibly have files of the same name (e.g.
Makefile) in different directories, and with a common 'undodir',
undofiles for all those identically-named files would overwrite each
other. Placing undofiles in the directory of the file makes sure that
the undofiles for vim73/Makefile, vim73/src/Makefile,
vim73/src/po/Makefile and vim73/src/testdir/Makefile won't destroy each
other.
Best regards,
Tony.
--
Q: How does a UNIX Guru pick up a girl?
A: look; grep; which; eval; nice; uname; talk; date;
Jordan Lewis
On 24/05/10 22:30, Jordan Lewis wrote:
[...]The default Bram chose is not the "current" directory (as of :cd or :lcd) but the directory of the file. The advantage of this choice is that you could quite possibly have files of the same name (e.g. Makefile) in different directories, and with a common 'undodir', undofiles for all those identically-named files would overwrite each other. Placing undofiles in the directory of the file makes sure that the undofiles for vim73/Makefile, vim73/src/Makefile, vim73/src/po/Makefile and vim73/src/testdir/Makefile won't destroy each other.
I am a bit concerned with your decision to write undo files to the
current directory by default, though. I think that it is "impolite" to
users to have Vim store its state (especially at the
1-statefile-per-file rate that undo persistence uses) directly in the
user's working directory. It makes more sense to me to use an undo
directory within ~/.vim by default. If that fails, then the right thing
to do would be to go ahead and write in the file's directory since, as
you mentioned, it is likely to succeed.
I suppose the argument could be made that the user who has added undo
persistence to her vimrc would have read enough of the documentation to
know that she must also set undodir if she doesn't want a polluted
current working directory. I don't think that this argument is strong
enough to warrant using the new default behavior, though, since a less
clued-in user might not understand why his working directory is suddenly
full of dot files.
- Jordan Lewis
Best regards,
Tony.
Jordan Lewis
Andy Kittner
>
>I suppose most people will want Python 2.6. I'll see if I manage to
>make that work. You can try it yourself, if you like.
>
>I also have a patch to support Python 3. We'll have to see if
>dynamically loading both will work. I don't know if anyone tried that.
I have tested with it on my 64 bit linux box, as well as in an 32 bit windows
xp virtual machine. Seems to work fine in both so far (apart from the
UCS2 vs. UCS4 issue, see my reply to Rolands updated patch in the
"Planning Vim 7.3" thread)
Regards,
Andy
--
I find that those who have to use profanity as a means of emphasis,
usually have nothing worth listening to.
-- HJohnson
Michael Wookey
>
> As you may have noticed, I have added the persistent undo patch
> yesterday.
Christian Brabandt
> I also changed it to put the undofile with the edited file. That should
> work, as writing a file usually means the undofile can be written there
> as well. It's possible to change this with the 'undodir' option.
edits certain files. But what about project directories, that are
accessed by several people? .<names>.un~ files would accumulate (and
since I usually have to work on Windows, they will even be visible for
everybody). This might be a problem for production servers, on which
only certain files are allowed to be. Well, I guess I have to set
'undodir'. (Will it be possible to set 'undodir' only for certain files
via e.g. autocommands?)
> Note that despite the checks it might still be possible that the undo
> information is corruped and changes your text in unexpected ways. Be
> careful.
BTW: If the undolevels setting is negative, you won't need to write a
undo-file, right? And secondly using the provided binary, I could not
successfully read in an undo file. I always get this error message:
"File contents changed, cannot use undo info"
Oh and for some reason, my vim was killed several times, when I tried
the vim73 beta. Unfortunately, I am on Windows and did not get any error
message so I don't know how to debug this. The first time I noticed, was
when I tried to write a large Textfile. Don't know, if this was related
to the undo-file settings, which was turned on.
This should be:
ftp://ftp.vim.org/pub/vim/unstable/pc/gvim73a.exe
regards,
Christian
Milan Vancura
> very easy to misplace the undo file. Also, when a file is edited by
> several people, or the same person with different login names or from
> different systems, the undo file would go in the wrong place. Also
> problems with renaming a directory, moving a directory tree, backups,
> etc.
file. So they should share the undo file?! Or there will be one undo file for
each user? And what if the user is unknown, for example on network-attached
disks where the original user (from the far computer) even does not exist on
the local one? And what about directories where it is not a good idea to create
files without a very good reason like directories exported via http,
directories under version control etc. etc. Imagine usual user of mercurial or
Novell BuildService: they use the command "addremove" quite often. And if there
was a file created automatically on the background they add it to the repository
accidentally. This is not a good idea, is it?
And there are many other examples. Status files of the editor should be in the
storage area reserved for such editor. In this case it is ~/.vim (on UN*X)
This is the (unspoken?) rule valid for decades on UN*X systems.
Yes, it means that we loose some automatic features you probably meant like
a persistent undo working over file transfer on USB key from comp1 to comp2.
But this is not what should be done by editor, at least not by default. The
list of complications is much longer and more serious than such advantage.
I vote for following standards in this case.
Milan
Tony Mechelynck
[...]
> file as you indicate. And the patch doesn't blindly name all undo files
> the same if they have the same filename - with a common undo directory,
> the files will be named path_to_vim73_Makefile.un~,
> path_to_vim73_src_Makefile.un~, etc.
>
> - Jordan
'undofile' it is said that the "name" of the undofile is specified by
'undodir', but 'undodir' specifies the _directory_ of the undofile,
resending to 'backupdir' for details, but nowhere (that I can find) does
the help specify the _name_ of the undo file.
The version of the help file I'm looking at is:
*options.txt* For Vim version 7.3a. Last change: 2010 May 13
Best regards,
Tony.
--
Windows
M!uqomz
James Vega
> On 24/05/10 23:52, Jordan Lewis wrote:
> [...]
> >I should have worded my post better - I did mean the directory of the
> >file as you indicate. And the patch doesn't blindly name all undo files
> >the same if they have the same filename - with a common undo directory,
> >the files will be named path_to_vim73_Makefile.un~,
> >path_to_vim73_src_Makefile.un~, etc.
> >
> >- Jordan
>
> Ah, well, I guess that's one detail missing in the help: under
> 'undofile' it is said that the "name" of the undofile is specified
> by 'undodir', but 'undodir' specifies the _directory_ of the
> undofile, resending to 'backupdir' for details, but nowhere (that I
> can find) does the help specify the _name_ of the undo file.
From :help 'undodir'
"." means using the directory of the file. The undo file name for
"file.txt" is ".file.txt.un~".
For other directories the file name is the full path of the edited
file, with path separators replaced with "%".
Bram Moolenaar
like swap files.
When putting undo files in a specified undo directory they are not
hidden. The file name is completely different then: It is the full path
with path separators changed to '%'.
That's what happens now, right?
Problem with the full path is that when a directory name is changed the
undo file is no longer found. Won't be deleted either.
For Unix we could store the inode/device instead of using the
mangled full path. Unfortunately that's not fully reliable either.
The device changes for network file systems.
--
I AM THANKFUL...
...for the mess to clean after a party because it means I have
been surrounded by friends.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
James Vega
> James Vega wrote:
> > Are the undo files supposed to be hidden when 'undodir' is not the
> > current directory? If so, that's not currently the case.
>
> When putting undo files with the edited files they are made hidden, just
> like swap files.
>
> When putting undo files in a specified undo directory they are not
> hidden. The file name is completely different then: It is the full path
> with path separators changed to '%'.
>
> That's what happens now, right?
It is. I just hadn't fully read the help when I sent the email and was
expecting, for some reason, the undo files to always be hidden
regardless of the directory they are stored in.
Tony Mechelynck
Best regards,
Tony.
--
Whistler's Law:
You never know who is right, but you always know who is in
charge.
Bram Moolenaar
Christian Brabandt wrote:
> On Mon, May 24, 2010 10:06 pm, Bram Moolenaar wrote:
> > I also changed it to put the undofile with the edited file. That should
> > work, as writing a file usually means the undofile can be written there
> > as well. It's possible to change this with the 'undodir' option.
>
> Is this a good idea? Generally I wouldn't mind if I am the only one who
> edits certain files. But what about project directories, that are
> accessed by several people? .<names>.un~ files would accumulate (and
> since I usually have to work on Windows, they will even be visible for
> everybody). This might be a problem for production servers, on which
> only certain files are allowed to be. Well, I guess I have to set
> 'undodir'. (Will it be possible to set 'undodir' only for certain files
> via e.g. autocommands?)
edited by someone else, using Vim, you can undo his changes. That can
be very useful. On the other hand, the undo file will reveal anything
you undid, perhaps things you never wanted others to see.
We probably need to add an example for a BufWritePre autocommand that
only sets 'undofile' for files under your home directory. Perhaps this
works:
set noundofile
au BufWritePre $HOME/* setlocal undofile
Untested!
Another solution would be to always have 'undofile' set and change
'undodir' depending on the file name.
> > Note that despite the checks it might still be possible that the undo
> > information is corruped and changes your text in unexpected ways. Be
> > careful.
>
> Yes I have noted that.
>
> BTW: If the undolevels setting is negative, you won't need to write a
> undo-file, right?
old file should still be deleted, as it will no longer be valid.
> And secondly using the provided binary, I could not
> successfully read in an undo file. I always get this error message:
> "File contents changed, cannot use undo info"
> Oh and for some reason, my vim was killed several times, when I tried
> the vim73 beta. Unfortunately, I am on Windows and did not get any error
> message so I don't know how to debug this. The first time I noticed, was
> when I tried to write a large Textfile. Don't know, if this was related
> to the undo-file settings, which was turned on.
> > You can try the self-installing executable:
> > ftp://ftp.vim.org/pub/vim/unstable/gvim73a.exe
>
> This should be:
> ftp://ftp.vim.org/pub/vim/unstable/pc/gvim73a.exe
--
I AM THANKFUL...
...for the clothes that fit a little too snug because it
means I have more than enough to eat.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Nikolai Weibull
> On Mon, May 24, 2010 10:06 pm, Bram Moolenaar wrote:
>> I also changed it to put the undofile with the edited file. That should
>> work, as writing a file usually means the undofile can be written there
>> as well. It's possible to change this with the 'undodir' option.
> Is this a good idea? Generally I wouldn't mind if I am the only one who
> edits certain files. But what about project directories, that are
> accessed by several people? .<names>.un~ files would accumulate (and
> since I usually have to work on Windows, they will even be visible for
> everybody). This might be a problem for production servers, on which
> only certain files are allowed to be. Well, I guess I have to set
> 'undodir'. (Will it be possible to set 'undodir' only for certain files
> via e.g. autocommands?)
production servers or network file-systems. All modifications should
be done to local copies (under version control) that are then
installed with make/install or similar solutions. This way of working
avoids all sorts of problems, like messed up permission and ownership,
stale auxiliary files (such as the undo files), and overwritten
changes (when someone else edits the same file as you at the same
time).
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.
Dimitar DIMITROV
> just a big pile of potential problems. Persistent undo is in the
> version control system, not in the editor.
Shouldn't Vim be used for purely text editing tasks only?
--
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
Bram Moolenaar
Michael Wookey wrote:
> On 25 May 2010 06:06, Bram Moolenaar <Br...@moolenaar.net> wrote:
> >
> > As you may have noticed, I have added the persistent undo patch
> > yesterday.
>
> There is a minor typo in the doc for 'persistent-undo'. Patch attached.
--
Bare feet magnetize sharp metal objects so they point upward from the
floor -- especially in the dark.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Mikolaj Machowski
> > When editing a file over a network or a removable media (USB stick) it's
> > very easy to misplace the undo file. Also, when a file is edited by
> > several people, or the same person with different login names or from
> > different systems, the undo file would go in the wrong place. Also
> > problems with renaming a directory, moving a directory tree, backups,
> > etc.
>
> I see many problems with this solution: more people than one can edit the
> same file. So they should share the undo file?!
m.
Dominique Pellé
> 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.
And even if you do use a version control system, persistent undo
allows you to undo with a smaller granularity than simply
reverting revisions in version control system.
Users of Vim find different features more or less useful.
I don't use all features. Does anybody use all Vim features? :-)
I don't use the GUI or tabs for example. But I can see that
other people find them useful and I would not call them useless.
Maybe persistent undo is not for everybody, but I'm confident it
will be useful to many, including myself.
Cheers
-- Dominique
Nikolai Weibull
>> 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.
> I think this is a bit harsh.
> Not every file is in version control.
> And even if you do use a version control system, persistent undo
> allows you to undo with a smaller granularity than simply
> reverting revisions in version control system.
whenever he saved. Not that I’d recommend that, but that’s a
solution.
> Users of Vim find different features more or less useful.
just above floating point numbers.
Christian Brabandt
On Di, 25 Mai 2010, Nikolai Weibull wrote:
> 2010/5/25 Dominique Pellé <dominiq...@gmail.com>:
> > Nikolai Weibull wrote:
> >> 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.
>
> > I think this is a bit harsh.
>
> And I think persistent undo is a lot problematic and only a bit useful.
>
> > Not every file is in version control.
>
> And that’s the problem.
constraints that prevent you from using an VCS System only for yourself.
And you can't always change that.
> > And even if you do use a version control system, persistent undo
> > allows you to undo with a smaller granularity than simply
> > reverting revisions in version control system.
>
> One user added a FileWritePost autocmd to commit changed files to Git
> whenever he saved. Not that I’d recommend that, but that’s a
> solution.
zsh: command not found: git
zsh: exit 127 git
> > Users of Vim find different features more or less useful.
>
> And persistent undo is on par with window tabs in terms of usefulness,
> just above floating point numbers.
at compile time. Or even use vim7.
regards,
Christian
Nikolai Weibull
> On Di, 25 Mai 2010, Nikolai Weibull wrote:
>> 2010/5/25 Dominique Pellé <dominiq...@gmail.com>:
>> > Nikolai Weibull wrote:
>> >> 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.
>>
>> > I think this is a bit harsh.
>>
>> And I think persistent undo is a lot problematic and only a bit useful.
>
> And now what?
> As I said, nobody forces you to use vim 7.3.
to come in and say basically the same thing in response to my opinion?
It’s not like I’m suggesting that it be removed.
I’m just stating the claim that what you really want is real version
control, not a half-assed form of it.
Christian J. Robinson
> And no one forced you to defend this feature.
True, nobody is forcing anybody to defend the feature, but what do you
expect to happen when you complain about it?
> Why does everyone have to come in and say basically the same thing
> in response to my opinion?
Why do you have to state, and re-state your opinion in the first
place?
> It�s not like I�m suggesting that it be removed.
Again I have to ask: Then why did you complain at all?
To me it seems like you're implying that since it can't be perfect--by
YOUR definition of perfection, for YOUR use cases--that it shouldn't
be there at all.
> I�m just stating the claim that what you really want is real version
> control, not a half-assed form of it.
I am looking forward to the persistent undo feature, and no, "real
version control" is _not_ what I want; I have access to various
version control systems, and I do use them, but I still want _this_
feature in Vim.
Yes, I agree that there will be problems, and that it's yet another
feature, and so on. It still has merit, and considering it's #4 on
the voting page means that a lot of people think so.
(http://www.vim.org/sponsor/vote_results.php)
Version control has its place, and this feature has its place. Just
because it can't always be shared doesn't make it "useless," as you
stated in an earlier reply. (Of course, you also said "only a bit
useful" in another reply--which is it?)
- Christian
--
Christian J. Robinson <hep...@gmail.com>
Nikolai Weibull
> On Tue, 25 May 2010, Nikolai Weibull wrote:
>
>> And no one forced you to defend this feature.
>
> True, nobody is forcing anybody to defend the feature, but what do you
> expect to happen when you complain about it?
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”.
>> Why does everyone have to come in and say basically the same thing in
>> response to my opinion?
> Why do you have to state, and re-state your opinion in the first place?
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.
>> It’s not like I’m suggesting that it be removed.
> Again I have to ask: Then why did you complain at all?
Because I like complaining and because the person that responded to my
post was too dismissive.
> To me it seems like you're implying that since it can't be perfect--by YOUR
> definition of perfection, for YOUR use cases--that it shouldn't be there at
> all.
Oh, was that what I implied? I didn’t realize. Perhaps I missed
reading one of my posts. (See below for a discussion on what I
actually wanted to imply.)
>> I’m just stating the claim that what you really want is real version
>> control, not a half-assed form of it.
> Yes, I agree that there will be problems, and that it's yet another feature,
> and so on. It still has merit, and considering it's #4 on the voting page
> means that a lot of people think so.
> (http://www.vim.org/sponsor/vote_results.php)
Which doesn’t necessarily mean that it will be as useful as those
people may hope.
> Version control has its place, and this feature has its place. Just because
> it can't always be shared doesn't make it "useless," as you stated in an
> earlier reply. (Of course, you also said "only a bit useful" in another
> reply--which is it?)
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.
François Ingelrest
> Does anybody use all Vim features? :-)
Does anybody actually know all Vim features? :-)
Sometimes I accidentally quit Vim while editing a file (hitting w and
q at the same time when saving for instance), losing the undo history
at the same time. I can certainly see a utility to persistent undo for
such cases.
Even if this feature will not be the most useful to me, I'm glad to
see new features added to Vim that make it even better.
Bram Moolenaar
Milan Vancura wrote:
> > When editing a file over a network or a removable media (USB stick) it's
> > very easy to misplace the undo file. Also, when a file is edited by
> > several people, or the same person with different login names or from
> > different systems, the undo file would go in the wrong place. Also
> > problems with renaming a directory, moving a directory tree, backups,
> > etc.
>
> I see many problems with this solution: more people than one can edit
> the same file. So they should share the undo file?! Or there will be
> one undo file for each user?
There needs to be one undo file, otherwise it would not work. If user A
edits a file and saves the undo file, then user B makes a change to the
file, the undo file of user A is no longer valid and will not work.
Only when the undo file is shared it would actually be possible to undo
with multiple users.
This is moot though, a file edited by several people is very unusual,
and if it does happen an undo file won't be very useful. Better not
enable the undofile option for this kind of file.
> And what if the user is unknown, for example on network-attached disks
> where the original user (from the far computer) even does not exist on
> the local one?
Normally such a user cannot save a file, as permissions cannot be
checked.
> And what about directories where it is not a good idea to create
> files without a very good reason like directories exported via http,
> directories under version control etc. etc. Imagine usual user of
> mercurial or Novell BuildService: they use the command "addremove"
> quite often. And if there was a file created automatically on the
> background they add it to the repository accidentally. This is not a
> good idea, is it?
On published directories you already have to take care not to store
backup files. Undo files are similar to that.
The undo files are hidden, all version control systems I know will
ignore them. E.g. swap files are normally not a problem.
> And there are many other examples. Status files of the editor should
> be in the storage area reserved for such editor. In this case it is
> ~/.vim (on UN*X) This is the (unspoken?) rule valid for decades on
> UN*X systems.
The undo files are not status files, they contain the text of the edited
file. I don't know of the rule you mention, do you have a reference?
> Yes, it means that we loose some automatic features you probably meant
> like a persistent undo working over file transfer on USB key from
> comp1 to comp2. But this is not what should be done by editor, at
> least not by default. The list of complications is much longer and
> more serious than such advantage.
I don't agree. Renaming a directory is very common, and would cause all
undo information stored below it to be lost. Loss of data is much more
serious than all the things you mention.
> I vote for following standards in this case.
What standards are you referring to? Without a reference it is no more
than your personal preference.
--
From "know your smileys":
C=}>;*{)) Drunk, devilish chef with a toupee in an updraft,
a mustache, and a double chin
Jordan Lewis
I figured that “That said, I think persistent undo is more or less
useless and, well, just a big pile of potential problems. Persistentundo 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.
Nikolai Weibull
> 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.
% git checkout -- Makefile
> 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.
% <<EOF >> Makefile
install_and_reload:
install httpd.conf && /etc/init.d/apache reload
EOF
% vim httpd.conf
# Edit
:mak[e] install_and_reload
# Edit more
@:
:make even saves the buffer for you, so that’s all you need to do.
> 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.
If you’re referring to a lot of unnecessary git commits, which, again,
I wasn’t suggesting, you can always use git rebase --interactive to
weed out, join, and reorder commits.
Christian Brabandt
On Di, 25 Mai 2010, Bram Moolenaar wrote:
> Christian Brabandt wrote:
>
> This completely depends on what you are doing. When a file has been
> edited by someone else, using Vim, you can undo his changes. That can
> be very useful. On the other hand, the undo file will reveal anything
> you undid, perhaps things you never wanted others to see.
>
> We probably need to add an example for a BufWritePre autocommand that
> only sets 'undofile' for files under your home directory. Perhaps this
> works:
>
> set noundofile
> au BufWritePre $HOME/* setlocal undofile
>
> Untested!
Not sure this works. Further testing shows, that the provided binary
crashes always when using :wundo <filename> (doesn't matter what
undofile is set to). This does not happen with a self built mingw binary
or a cygwin binary.
> > BTW: If the undolevels setting is negative, you won't need to write a
> > undo-file, right?
>
> Yes, when there is no undo info the file should not be written. But an
> old file should still be deleted, as it will no longer be valid.
But if I set ul=-1 an undofile will still be written.
If I understand the code corectly, this should fix it:
chrisbra t41:~/vim/src [1070]% hg diff undo.c
diff -r 271a5907f944 src/undo.c
--- a/src/undo.c Tue May 25 22:09:21 2010 +0200
+++ b/src/undo.c Tue May 25 22:54:13 2010 +0200
@@ -1265,6 +1265,14 @@
perm = 0600;
#endif
}
+ if (p_ul <0)
+ {
+ mch_remove(file_name);
+ if (p_verbose > 0)
+ smsg((char_u *)_("'undolevels' is negative, won't write the undofile: %s"),
+ file_name);
+ goto theend;
+ }
/* set file protection same as original file, but strip s-bit */
perm = perm & 0777;
regards,
Christian
Tony Mechelynck
[...]
> The undo files are hidden, all version control systems I know will
> ignore them. E.g. swap files are normally not a problem.
For a counterexample, Mercurial tracks files regardless of an initial
dot: .hgignore is specifically mentioned as tracked, and I've also seen
it mentioning src/.version.c.swp when I did hg status with a file open
in Vim.
Best regards,
Tony.
--
What the large print giveth, the small print taketh away.
Tony Mechelynck
> Hi Nikolai!
>
> On Di, 25 Mai 2010, Nikolai Weibull wrote:
>
>>> Nikolai Weibull wrote:
>>>> 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.
>>
>>> I think this is a bit harsh.
>>
>> And I think persistent undo is a lot problematic and only a bit useful.
>
> And now what? You can always disable it at compile time.
>
>>
>>> Not every file is in version control.
>>
>
> You don't always have a VCS System available. Sometimes there are
> constraints that prevent you from using an VCS System only for yourself.
> And you can't always change that.
>
>>> And even if you do use a version control system, persistent undo
>>> allows you to undo with a smaller granularity than simply
>>> reverting revisions in version control system.
>>
>> One user added a FileWritePost autocmd to commit changed files to Git
>> solution.
>
> chrisbra t41:~/vim [1008]% git
> zsh: command not found: git
> zsh: exit 127 git
>
>>> Users of Vim find different features more or less useful.
>>
>> And persistent undo is on par with window tabs in terms of usefulness,
>> just above floating point numbers.
>
> As I said, nobody forces you to use vim 7.3. You can always disable it
> at compile time. Or even use vim7.
>
> regards,
> Christian
>
Nikolai:
When tab pages appeared in Vim 7.00aa, I regarded them as not really
useful, only good for people who didn't understand the power of
split-windows (and yet I wrote an enhanced 'tabline' function, which I
still use, even before the 'guitablabel' option existed). Now that I
have so many split windows that their status lines use just about half
the screen height (even with 'winminheight' set to zero: &lines == 49,
winnr('$') == 25), I've started keeping the help on its own tab.
As for floating point numbers, I constantly use Vim as a floating-point
calculator; I wouldn't say it's a useless feature. Not a /necessary/ one
-- I could do without the trig and exp/log functions, and I could even
supply additional decimals by scaling, and evaluate orders of magnitude
mentally, as I did when using a slide rule in high school and college --
but useful, yes, and at no marginal cost (especially now that Bill's
additional functions are part of Vim 7.3a, so even the risk of bit-rot
is gone).
I don't use persistent undo (yet?), any more than I use the +perl,
+python, +ruby, +tcl, +clientserver and +profile features (and probably
a lot more) yet they're all compiled into my "Huge" gvim build. Who
knows? I may use them some day. The only "feature" which I've
specifically excluded from this build (by editing feature.h) is
+tag_old_static, as I believe that the probability that I'll ever need
that one is _really_ vanishingly small.
Best regards,
Tony.
--
Q: How many hardware engineers does it take to change a lightbulb?
A: None. We'll fix it in software.
Tony Mechelynck
> 2010/5/25 Dominique Pell�<dominiq...@gmail.com>:
Yes, so do I. One advantage of all those features is that (a) different
people will use different features, and (b) since they are modular, it
is easy to recompile Vim with a different set of features (as long as
they're compatible: for an extreme case, trying to include +float with
-eval seems rather pointless), and even with your name on it. Vim
doesn't go as far as Firefox what regards optional installable features,
yet there are already a goodly number of third-party scripts (which
don't even require recompilation) and of "unofficial patches" (a few of
which have already become "official" parts of Vim 7.3) at vim.org,
groups.google.com, and elsewhere.
And as I said elsewhere in this thread a few minutes ago, including a
feature which I don't use (yet) may mean that later (sometimes years
later, as in the case of tabpages) I'll find a use for it.
Best regards,
Tony.
--
Call on God, but row away from the rocks.
-- Indian proverb
Bram Moolenaar
Tony Mechelynck wrote:
> On 25/05/10 22:37, Bram Moolenaar wrote:
> [...]
> > The undo files are hidden, all version control systems I know will
> > ignore them. E.g. swap files are normally not a problem.
> [...]
>
> For a counterexample, Mercurial tracks files regardless of an initial
> dot: .hgignore is specifically mentioned as tracked, and I've also seen
> it mentioning src/.version.c.swp when I did hg status with a file open
> in Vim.
Yeah, Mercurial is a bit annoying, it does ignore it's own files (.hg,
.hgtags) but not others. I'm sure they had a long discussion about
that.
I did add a "~" to the file name, so that .hgignore files that are
already setup to ignore backup files also won't see the undo files.
--
hundred-and-one symptoms of being an internet addict:
101. U can read htis w/o ny porblm and cant figur eout Y its evn listd.
Ben Fritz
On May 25, 3:37 pm, Bram Moolenaar <B...@Moolenaar.net> wrote:
> This is moot though, a file edited by several people is very unusual,
> and if it does happen an undo file won't be very useful. Better not
> enable the undofile option for this kind of file.
>
I haven't had time to try out the Vim 7.3 stuff. Is persistent undo a
buffer-local option? It sounds like perhaps it should be, so that
users can easily turn it on and off on a per-file basis. Of course, I
would say the same about 'backup', which is unfortunately a global
option.
Ben Fritz
On May 26, 7:32 am, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:
>
> As for floating point numbers, I constantly use Vim as a floating-point
> calculator; I wouldn't say it's a useless feature. Not a /necessary/ one
> -- I could do without the trig and exp/log functions
When floating point was included, I thought it to be fairly useless,
more of a "look what my editor can do!" feature without much real use.
When I want to calculate things, I generally use a calculator.
All that changed when I had to compute a trig function on a large
number of items scattered through a text file. I don't remember why I
needed to do this...it may have been in a debug log file from some
code I was working on, or maybe in some code itself with hard-coded
numbers I needed to check. Regardless, it was simple to do a :g
command to find each number and print out the number and its output
for each case. I did in seconds what it may have taken a good part of
an hour doing by hand, finding each input and plugging it into
Windows' Calculator application, or even into a spreadsheet.
I've found many other uses since then, including quick calculations
made faster by the support for things like getting the word under the
cursor.
Persistent undo sounded originally to me like something that would be
a neat feature, but that I wouldn't use much. Nevertheless, I think
that I will turn it on and give it a try. And sometime, like with
floating point, I'll find a specific situation where I'm incredibly
grateful to have it.
Christian J. Robinson
> Is persistent undo a buffer-local option? It sounds like perhaps it
> should be, so that users can easily turn it on and off on a per-file
> basis.
I agree that this is an option that should be possible to set locally.
Setting it with ":set" should default to global, but using ":setlocal"
should work too.
> Of course, I would say the same about 'backup', which is
> unfortunately a global option.
There are a few options that I wish were global by default but could
also be set locally, such as 'clipboard' now that it accepts an "html"
argument.
James Vega
> On May 25, 3:37 pm, Bram Moolenaar <B...@Moolenaar.net> wrote:
>> This is moot though, a file edited by several people is very unusual,
>> and if it does happen an undo file won't be very useful. Better not
>> enable the undofile option for this kind of file.
>>
>
> I haven't had time to try out the Vim 7.3 stuff. Is persistent undo a
> buffer-local option?
'undodir' is global, 'undofile' is buffer-local.
Nikolai Weibull
> On May 26, 7:32 am, Tony Mechelynck <antoine.mechely...@gmail.com>
> wrote:
>> As for floating point numbers, I constantly use Vim as a floating-point
>> calculator; I wouldn't say it's a useless feature. Not a /necessary/ one
>> -- I could do without the trig and exp/log functions
> When floating point was included, I thought it to be fairly useless
> All that changed when I had to compute a trig function on a large
> number of items scattered through a text file.
> I did in seconds what it may have taken a good part of
> an hour doing by hand, finding each input and plugging it into
> Windows' Calculator application, or even into a spreadsheet.
Perhaps you would like to give dc(1) a try next time?
Bram Moolenaar
Ben Fritz wrote:
> On May 25, 3:37=A0pm, Bram Moolenaar <B...@Moolenaar.net> wrote:
> > This is moot though, a file edited by several people is very unusual,
> > and if it does happen an undo file won't be very useful. =A0Better not
> > enable the undofile option for this kind of file.
> >
>
> I haven't had time to try out the Vim 7.3 stuff. Is persistent undo a
> buffer-local option? It sounds like perhaps it should be, so that
> users can easily turn it on and off on a per-file basis. Of course, I
> would say the same about 'backup', which is unfortunately a global
> option.
The 'undofile' option is local to the buffer. Thus you can use ":set
undofile" and all buffers opened will use that value, but ":setlocal
undofile" will only set it for the current buffer.
I have not heard a request for 'backup' to be buffer-local. We do have
the 'backupskip' option. Would we need a 'undofileskip' option? And
perhaps a "undofileapply" option for the opposite? I think using the
buffer-local option in combination with an autocommand will work just as
well. If I remember correctly, 'backupskip' was added before
autocommands.
--
hundred-and-one symptoms of being an internet addict:
105. When someone asks you for your address, you tell them your URL.
Markus Heidelberg
>
> Tony Mechelynck wrote:
>
> > On 25/05/10 22:37, Bram Moolenaar wrote:
> > [...]
> > > The undo files are hidden, all version control systems I know will
> > > ignore them. E.g. swap files are normally not a problem.
> > [...]
> >
> > For a counterexample, Mercurial tracks files regardless of an initial
> > dot: .hgignore is specifically mentioned as tracked, and I've also seen
> > it mentioning src/.version.c.swp when I did hg status with a file open
> > in Vim.
>
> Yeah, Mercurial is a bit annoying, it does ignore it's own files (.hg,
> .hgtags) but not others.
And that's the right thing to do. A VCS shouldn't add this kind of
policy. If dot files were ignored by default, they would be hidden in
"hg status" and you would forget to add them for tracking (.hgignore for
example).
You can still add something like .*.swp to .hgignore for the swap files.
Markus
Tony Mechelynck
I would add not only .*.swp but even .*.sw? (to ignore .swo .swn etc.),
src/auto/config.mk (which is regenerated by configure from the
config.mk.dist and a couple of others) and runtime/doc/tags (which is
regenerated by make install). However, maybe I'm talking from a
"provincial" Linux standpoint: I'm fairly certain that users of
makefiles other than Makefile don't need src/auto/config.mk but what
about the help tags? I guess all makefiles "ought" to rebuild them at
some point but do they?
Ah, and shadow directories. In theory they can be named anything (below
src/ ) but the default is src/shadow and I propose to also "ignore"
src/shadow-* in case someone had several shadow directories -- with a
notice somewhere (maybe as a comment in either or both of the
src/Makefile and .hgignore) that shadow-<something> is the preferred
name. Then src/runtime and src/pixmaps (softlinks created by make
shadow) and src/cscope.out (just to be on the safe side in case someone
built a cscope database for the Vim source).
What have we forgotten? Ah yes, src/auto/if_perl.c (on Linux) and
src/if_perl.c (on Windows). Is that all now?
Best regards,
Tony.
--
Conservative, n.:
One who admires radicals centuries after they're dead.
-- Leo C. Rosten
Xavier de Gaye
>> ...
>
> I would add not only .*.swp but even .*.sw? (to ignore .swo .swn etc.),
> src/auto/config.mk (which is regenerated by configure from the
> config.mk.dist and a couple of others) and runtime/doc/tags (which is
> regenerated by make install). However, maybe I'm talking from a "provincial"
> Linux standpoint: I'm fairly certain that users of makefiles other than
> Makefile don't need src/auto/config.mk but what about the help tags? I guess
> all makefiles "ought" to rebuild them at some point but do they?
src/auto/config.mk and runtime/doc/tags are under mercurial control,
they sould not be added to .hgignore (or they should be removed from
mercurial control):
$ hg locate | grep "config.mk$"
src/auto/config.mk
$ hg locate | grep "runtime.*tags$"
runtime/doc/tags
> Ah, and shadow directories. In theory they can be named anything (below src/
> ) but the default is src/shadow and I propose to also "ignore" src/shadow-*
> in case someone had several shadow directories -- with a notice somewhere
> (maybe as a comment in either or both of the src/Makefile and .hgignore)
> that shadow-<something> is the preferred name. Then src/runtime and
> src/pixmaps (softlinks created by make shadow) and src/cscope.out (just to
> be on the safe side in case someone built a cscope database for the Vim
> source).
I suggest to add also src/tags.
> What have we forgotten? Ah yes, src/auto/if_perl.c (on Linux) and
> src/if_perl.c (on Windows). Is that all now?
Xavier
Markus Heidelberg
> On 28/05/10 01:54, Markus Heidelberg wrote:
> > You can still add something like .*.swp to .hgignore for the swap files.
>
Yes, that would make sense.
> src/auto/config.mk (which is regenerated by configure from the
> config.mk.dist and a couple of others) and runtime/doc/tags (which is
> regenerated by make install).
But since these files are tracked by hg, you cannot ignore them. It's
annoying that the worktree is dirty after each "make install".
Automatically generated files shouldn't be tracked. In the git
repository I removed src/auto/config.mk because of this, but apparently
it is needed in some situations. In .hgignore there is the comment "We
do need src/auto/configure and src/auto/config.mk."
> However, maybe I'm talking from a
> "provincial" Linux standpoint: I'm fairly certain that users of
> makefiles other than Makefile don't need src/auto/config.mk but what
> about the help tags? I guess all makefiles "ought" to rebuild them at
> some point but do they?
I think the same and then the file could be deleted from the repository.
I guess it's included for people to update the runtime files from the
ftp server without doing "make install". Bram, do you continue to
support the ftp/rsync access for the runtime files? But runtime/doc/tags
could still be shipped via ftp, even if it's deleted in hg.
> Ah, and shadow directories. In theory they can be named anything (below
> src/ ) but the default is src/shadow and I propose to also "ignore"
> src/shadow-* in case someone had several shadow directories -- with a
> notice somewhere (maybe as a comment in either or both of the
> src/Makefile and .hgignore) that shadow-<something> is the preferred
> name.
I think we should stick to the defaults from the Makefiles to not
pollute the .hgignore too much. The next person wants to have the shadow
directory in src/.shadow or so. There are even opinions to only include
the files from the build process into the ignore rules and not include
something like *~ .*.sw? *.rej *.orig, which is dependent on personal
use. But it makes at least sense to ignore files generated by Vim in
Vim's repository. It's still possible to extend the ignore list in the
local clone, for example:
.hg/hgrc:
[ui]
ignore = ~/.hgignore-for-vim
> What have we forgotten? Ah yes, src/auto/if_perl.c (on Linux) and
> src/if_perl.c (on Windows). Is that all now?
This is the .gitignore from the git repository:
*.swp
*.exe
*.obj
*.dll
*.pdb
*.RES
*.exp
*.ilk
cscope.*
tags
/src/pathdef.c
/src/types.vim
/src/vim
/src/objects/
/src/obj*/
/src/gobj*/
/src/ObjG*/
/src/ObjC*/
# Automatically changed/filled files, shipped with Vim with minimal content.
# Deleted in this repository, otherwise this rules would have no effect.
/src/auto/config.h
/src/auto/config.mk
/src/auto/config.cache
/src/auto/config.log
/src/auto/config.status
/src/auto/if_perl.c
/src/auto/link.log
/src/auto/link.sed
/src/auto/osdef.h
/src/auto/pathdef.c
/src/po/*.ck
/src/po/*.mo
/src/po/sjiscorr
/src/testdir/test*.out
/src/testdir/small.vim
/src/testdir/tiny.vim
/src/testdir/mbyte.vim
/src/testdir/test.log
/src/xxd/xxd
/src/GvimExt/gvimext.dll
/src/GvimExt/gvimext.lib
/src/GvimExt/gvimext.o
/src/GvimExt/gvimext.res
Benjamin Fritz
>
> I have not heard a request for 'backup' to be buffer-local. We do have
> the 'backupskip' option. Would we need a 'undofileskip' option? And
> perhaps a "undofileapply" option for the opposite? I think using the
> buffer-local option in combination with an autocommand will work just as
> well. If I remember correctly, 'backupskip' was added before
> autocommands.
>
Well, I'll be...
I actually missed this option somehow.
No reason for a buffer-local backup option then.
If 'undofile' by itself allows you to turn off persistent undo for
particular files, then it should be sufficient, I do not think we need
an undofileskip setting.