Update on Vim 7.3 status

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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 -- [hidden email] -- 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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Nico-63
On May 24, 1:06 pm, Bram Moolenaar <[hidden email]> wrote:
> 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

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?

Nico

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Jordan Lewis-4
In reply to this post by Bram Moolenaar
On Mon, May 24, 2010 at 3:06 PM, Bram Moolenaar <[hidden email]> 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.

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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

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 <[hidden email]> 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.

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 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.

--
I AM THANKFUL...
...for the taxes that I pay because it means that I am employed.

 /// Bram Moolenaar -- [hidden email] -- 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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Bram Moolenaar
In reply to this post by Nico-63

Nico Raffo wrote:

> On May 24, 1:06=A0pm, Bram Moolenaar <[hidden email]> 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
> > for 64 bit systems, but it doesn't appear to work yet.
> >
> > You can try the self-installing executable:
> > =A0ftp://ftp.vim.org/pub/vim/unstable/gvim73a.exe
>
> 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?

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.

--
From "know your smileys":
 % Bike accident.  A bit far-fetched, I suppose; although...
             o      _     _         _
     _o     /\_   _ \\o  (_)\__/o  (_)
   _< \_   _>(_) (_)/<_    \_| \   _|/' \/
  (_)>(_) (_)        (_)   (_)    (_)'  _\o_

 /// Bram Moolenaar -- [hidden email] -- 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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

tux.
Bram Moolenaar schrob am 24.05.2010 22:56:
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.

It compiles without any problem in my builds. :-)

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

James Vega-3
In reply to this post by Bram Moolenaar
On Mon, May 24, 2010 at 10:56:59PM +0200, Bram Moolenaar wrote:

>
> 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 <[hidden email]>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Tony Mechelynck
In reply to this post by Jordan Lewis-4
On 24/05/10 22:30, Jordan Lewis wrote:
[...]

> 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

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.


Best regards,
Tony.
--
Q: How does a UNIX Guru pick up a girl?
A: look; grep; which; eval; nice; uname; talk; date;

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Jordan Lewis-4
On Mon, May 24, 2010 at 4:39 PM, Tony Mechelynck <[hidden email]> wrote:
On 24/05/10 22:30, Jordan Lewis wrote:
[...]

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

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.


Best regards,
Tony.

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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Jordan Lewis-4
In reply to this post by James Vega-3
On Mon, May 24, 2010 at 4:23 PM, James Vega <[hidden email]> wrote:
On Mon, May 24, 2010 at 10:56:59PM +0200, Bram Moolenaar wrote:
>
> 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.

No, they should not be hidden - in the common case of a dedicated directory for undo files, this behavior would be unnecessary, and possibly lead to confusion when the directory is examined and found at first glance to be empty.

- 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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Andy Kittner
In reply to this post by Bram Moolenaar
On Mon, May 24, 2010 at 10:56:59PM +0200, Bram Moolenaar wrote:
> [..]
>
>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

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Michael Wookey-3
In reply to this post by Bram Moolenaar
On 25 May 2010 06:06, Bram Moolenaar <[hidden email]> 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.

--
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

0001-fix-doc-typo-in-persistent-undo.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Christian Brabandt
In reply to this post by Bram Moolenaar
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?)

> 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? 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


regards,
Christian

--
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
Reply | Threaded
Open this post in threaded view
|

undo file location was: Re: Update on Vim 7.3 status

Milan Vancura
In reply to this post by Bram Moolenaar
> 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? 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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Tony Mechelynck
In reply to this post by Jordan Lewis-4
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.

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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Nikolai Weibull-11
In reply to this post by Christian Brabandt
On Tue, May 25, 2010 at 12:48, Christian Brabandt <[hidden email]> 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?)

If there’s one thing I’ve learned it’s that you should never work on
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.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

James Vega-3
In reply to this post by Tony Mechelynck
On Tue, May 25, 2010 at 01:21:43PM +0200, Tony Mechelynck wrote:

> 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 "%".

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Bram Moolenaar
In reply to this post by James Vega-3

James Vega wrote:

> On Mon, May 24, 2010 at 10:56:59PM +0200, Bram Moolenaar wrote:
> >
> > 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.

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?

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 -- [hidden email] -- 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
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

James Vega-3
On Tue, May 25, 2010 at 02:29:23PM +0200, Bram Moolenaar wrote:

> 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.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update on Vim 7.3 status

Tony Mechelynck
In reply to this post by James Vega-3
On 25/05/10 14:19, James Vega wrote:

> On Tue, May 25, 2010 at 01:21:43PM +0200, Tony Mechelynck wrote:
>> 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 "%".
>

My bad, I didn't read attentively enough.


Best regards,
Tony.
--
Whistler's Law:
        You never know who is right, but you always know who is in
charge.

--
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
123