Re: [PATCH] Set the buffer to be modified after recovery (was: Save recovered file with ZZ?)
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?)
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 (?)
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?
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?
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