On 16/04/10 09:15, Benjamin R. Haskell wrote:
On Fri, 16 Apr 2010, Tony Mechelynck wrote:
On 16/04/10 00:38, Benjamin R. Haskell wrote:
On 2010-04-15, Tony Mechelynck wrote:
On 15/04/10 19:35, Benjamin R. Haskell wrote:
[...]
Why isn't the file considered to be 'modified' after it's
changed by the recovery process? (Hence the 'ZZ' fails to save
it.)
I think it's a bug; see thread ":wa don't save recovered files"
started 2010-02-19 02:15 -0800 by "smith"< dmitriy DOT kuznetsov
AT gmail DOT com> on this ML.
Yep. Sounds like the same problem.
[...]
BTW which Vim version and patchlevel are you using? (as shown by
the first few lines of the output of :version, until the line
ending "Features included (+) or not (-):")
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Mar 5 2010 09:03:28)
Included patches: 1-376
Modified by Gentoo-7.2.376
Compiled by paludisbu...@hp
Huge version without GUI. Features included (+) or not (-):
Thanks as always, Tony.
Hm, 7.2.376, with unspecified mods by Gentoo.
The other reporter was using GVim on Vista. I'm going to guess the
Gentoo Linux mods (which AFAICT are compilation-error- and Gentoo
file-format syntax-related) aren't at fault. I think the 'Modified'
line is a CYA move on Gentoo's part.
I don't know if Bram's "latest of the greatest" source has a patch for
your problem (see http://ftp.vim.org/pub/vim/patches/7.2/README which
lists Bram's "official" patches to 7.2.411 as of this writing) but it
includes 35 bugfixes you haven't got (admittedly including a few
Windows ones I suppose, but usually most of them are
platform-agnostic) and using it would clear away the Gentoo mods, of
which we know nothing.
Nothing in the hg log reveals anything that would change this between
376 and 411.
Compiling Vim on Linux isn't really hard (once you have the
appropriate "development" packages installed), see
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm (and Bram
has recently set up a Mercurial repository for the Vim source, which
I'll mention on that page once I get around to trying it).
When Jean Johner's long-discussed "position is restored incorrectly on
line 1" came up, I set up a nice little script for hg-bisect'ing. And
it turned out to be a distro-dependent global vimrc issue. So, I don't
tend to quickly jump on the "I'll recompile Vim and see" bus anymore.
Especially when it's something that doesn't already seem
version-dependent (in the case of the "line 1" issue, it differed for me
between OpenSUSE 7.2.128(?) and Gentoo 7.2.280-or-so).
Recompiling usually also gets you rid of any distro-dependent global
vimrc (by using /usr/local/share/vim/vimrc if any rather than either
/etc/vimrc if any on some systems, or maybe /usr/share/vim/vimrc if any
on other systems) but of course checking first (with the help of
:version) whether you have a global vimrc and what it contains doesn't hurt.
I've seen people gripe about some bug, even propose a half-baked patch,
just to be told "that was fixed by the 15th-from last official patch,
published by Bram a month ago". How would you feel if it happened to you?
In this case, the behavior's the same on both systems.
Here's a script for reproducing the error easily on POSIX-y systems:
The first editing session will echo a 'kill -KILL ####' line, which can be
used from another terminal to kill the session unceremoniously. Then
use 'ZZ' or ':wa' in the second Vim session, and see that it's not
saved.
#!/bin/sh
f=/tmp/testfile
rm -f $f
vim +'set ut=100' $'+normal inot saved\e:w\n0dw\e:echo "kill -KILL
".getpid()\n' $f
vim $f
cat $f
Maybe this problem should be brought to Bram's attention and/or moved to
the vim_dev list?
Best regards,
Tony.
--
In a museum in Havana, there are two skulls of Christopher Columbus,
"one when he was a boy and one when he was a man."
-- Mark Twain
--
You received this message from the "vim_use" 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
Subscription settings: http://groups.google.com/group/vim_use/subscribe?hl=en
