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
/// Bram Moolenaar -- [email protected] -- 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
