Re: [PATCH] Set the buffer to be modified after recovery (was: Save recovered file with ZZ?)

2010-04-26 Fir de Conversatie Tom Sorensen
On Tue, Apr 20, 2010 at 6:09 PM, Christian Brabandt cbli...@256bit.org wrote:
 Hi Tom!

 On Sa, 17 Apr 2010, Tom Sorensen wrote:

 It also works differently on different platforms. I played around with
 a similar plugin (SwapExists.vim) that James wrote (iirc) about 6
 months ago and could not get it to work consistently on both Windows
 and Linux. I didn't even try for AIX, Solaris, or the other platforms
 I have access to.

 Where can I find that plugin?

http://github.com/godlygeek/vim-files/blob/master/plugin/SwapExistsDiff.vim

It was written by Matt Wozniski, not James. The issues I had with it
were that it would not perform correctly on both Windows and Linux. As
I recall (based on my log searches) it would do nothing the first time
you edited the file, but execute the second time. Some issue with the
BufWinEnter's executing out of the defined order. That was what I
found last June, and I stopped messing with it shortly after.

Tom

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

Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en


Re: [PATCH] Set the buffer to be modified after recovery (was: Save recovered file with ZZ?)

2010-04-26 Fir de Conversatie Matt Wozniski
On Mon, Apr 26, 2010 at 11:14 AM, Tom Sorensen wrote:
 It was written by Matt Wozniski, not James. The issues I had with it
 were that it would not perform correctly on both Windows and Linux. As
 I recall (based on my log searches) it would do nothing the first time
 you edited the file, but execute the second time. Some issue with the
 BufWinEnter's executing out of the defined order. That was what I
 found last June, and I stopped messing with it shortly after.

I've also found it to not work quite right on Solaris - the only
platform it seemed to work well enough on was Linux.  I'd be
interested to find out if the feedkeys-based approach works more
reliably.

~Matt

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

Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en


setqflist() inconsistency (?)

2010-04-26 Fir de Conversatie Christian Brabandt
Recently, I wondered how to clear the quickfix list (and location list).
My first try was to use setqflist() with an empty list. While this did
result in an empty quickfix list, it did not make :cw work as it was
supposed to be. I am not sure whether I am supposed to clear the
quickfix list like that, but I didn't expect, that this is not possible
using setqflist(). 
Then I found out that using :cgetexpr [] really clears the quickfix list 
and makes :cw work as expected. 

So here is a patch, that makes setqflist([]) behave as I would have
expected it. Admittedly this is a minor inconsistency, but when skimming
through the help, I did not easily find a way to clear the list, so I
thought this might be useful.

chrisbra t41:~/vim/src [1019]% hg diff quickfix.c ../runtime/doc/eval.txt
diff -r 24100651daa9 runtime/doc/eval.txt
--- a/runtime/doc/eval.txt  Tue Mar 23 18:22:46 2010 +0100
+++ b/runtime/doc/eval.txt  Mon Apr 26 22:39:24 2010 +0200
@@ -4944,6 +4944,8 @@
item will not be handled as an error line.
If both pattern and lnum are present then pattern will
be used.
+   If you supply an empty {list}, the quickfix list will be
+   cleared.
Note that the list is not exactly the same as what
|getqflist()| returns.

diff -r 24100651daa9 src/quickfix.c
--- a/src/quickfix.cTue Mar 23 18:22:46 2010 +0100
+++ b/src/quickfix.cMon Apr 26 22:39:24 2010 +0200
@@ -3654,7 +3654,10 @@
}
 }

-qi-qf_lists[qi-qf_curlist].qf_nonevalid = FALSE;
+if (qi-qf_lists[qi-qf_curlist].qf_index == 0)
+   qi-qf_lists[qi-qf_curlist].qf_nonevalid = TRUE;
+else
+   qi-qf_lists[qi-qf_curlist].qf_nonevalid = FALSE;
 qi-qf_lists[qi-qf_curlist].qf_ptr = 
qi-qf_lists[qi-qf_curlist].qf_start;
 qi-qf_lists[qi-qf_curlist].qf_index = 1;

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

Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en


Re: Windows 7 64bit - use 32bit or 64bit Vim?

2010-04-26 Fir de Conversatie George V. Reilly
On Mon, Apr 26, 2010 at 12:19 PM, David Fishburn dfishburn@gmail.comwrote:

 I regularily build my on Vim using VS 2008.

 I have just been upgraded to Windows 7 64bit and am beginning to set it up.

 Seems you always have to choose if you want (or can use) the 32bit
 version of software or find a 64bit version.

 Now, since I build my own Vim, I guess I can get VS 2008 to build me a
 64bit version of Vim.
 Here are my problems:

 1.  I use Perl plugins daily (Perl64 exists).
 2.  I use Python 2.5 (not that often, but a few plugins which use it),
 I am not certain if a 64 bit version of this exists.
 3.  All my other plugins written in VimScript should of course be fine.

 Even if I can compile my Vim using the 64bit Perl version, I am not
 certain if my perl modules have 64bit versions, or should that all be
 resolved when I simply install them?  Or do the authors have to make
 64bit changes to make them work in the first place?

 Just looking for some feedback on what others have done on the 64bit
 versions of Windows which are available these days.


I'm the maintainer of http://code.google.com/p/vim-win3264/. The main reason
for the existence of the Win64 version is Explorer integration. You have to
have a 64-bit version of gvimext.dll on Win64, so that you can right-click
in Explorer and get Vim-related commands. The other reason for the Win64
version is my quixotic quest to make Vim run cleanly on Win64. It's hard to
imagine anyone truly needing 4GB for their Vim process address space.

The actual (g)vim.exe binary doesn't need to be 64-bit. Win32 binaries run
fine on Win64. Indeed, it's simpler to build a 32-bit (g)vim.exe, as all the
language DLLs need to be available in 64-bit flavors too. The only language
that I know for sure works as a native Win64 DLL is Python 2.6. Even that
has problems if you're trying to run Python C extensions, since you have to
figure out how to get a Win64 build of the C extension. I gave up the last
time I tried. I'm using the 32-bit version of Python 2.6 on Win64.  (I think
the Win64 support in Python 2.5 is not recommended.)

I tried to build Vim with Ruby 1.9 DLL support earlier this month. I
abandoned the effort when I realized that the MinGW headers included with
Ruby 1.9 weren't going to compile with the MSVC compiler.

I've never tried to get a 64-bit version of Perl running with Win64 Vim.

I think a better solution would be a smarter Windows installer for Vim which
included Win32 and Win64 copies of gvimext.dll and a Win32 gvim.exe, that
installed the appropriate flavor of the shell extension DLL.
-- 
/George V. Reilly  geo...@reilly.org  Twitter: @georgevreilly
http://www.georgevreilly.com/blog  http://blogs.cozi.com/tech

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

Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en


RE: Windows 7 64bit - use 32bit or 64bit Vim?

2010-04-26 Fir de Conversatie Craig Barkhouse
George V. Reilly said:
 I think a better solution would be a smarter Windows installer for Vim which 
 included Win32 and Win64 copies of gvimext.dll and a Win32 gvim.exe, that 
 installed the appropriate flavor of the shell extension DLL.

There are still a few reasons why one might want a native 64-bit version of Vim:
1) Editing files  4GB in size, rare I know, but still.
2) 64-bit WinPE does not have a WOW64 subsystem, hence you cannot run a 32-bit 
executable.
3) Windows Server 2008 R2 (i.e. Win7 Server) also does not have the WOW64 
subsystem, by default, although it is an optional component you can install.
4) Potential for perf gains, particularly in heavy memory operations like 
memcpy and memcmp which can be optimized for the 64-bit word size.

Those are in addition to the Explorer integration issue that you mention.

I would definitely use the 64-bit Vim if it came in an official installer.  As 
it is, I don't use your (George) 64-bit binary, just because I like to use the 
vanilla official binary.

Craig

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

Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en