Re: How about a release?
On 3/18/2018 7:48 AM, Bram Moolenaar wrote: Justin M. Keyes wrote: I'm glad to give credits to developers who send me a patch that I can include and make Vim users happy. No matter where that code came from. Why give credit to NeoVim as a project, instead of its individual contributors? That would mean NeoVim helps Vim moving forward. As a sort of breeding ground for new Vim features, which you have hinted at before. Unfortunately, I see the opposite. Many thing that happened in NeoVim make it more difficult to take changes back to Vim. The code is refactored in a way that no bigger patch can be taken over. Tests are written in a way that won't work in Vim. And the mission statement "seeks to aggressively refactor Vim" is clearly saying this is all intentional. I fully admit I have been slow to include certain changes, for various reasons. And it's no surprise if the authors make their changes available in other ways, such as a fork with those changes applied. If they are serious in wanting these changes being included in Vim, they would make that easy to do. Christian has been very good in this, for example. And if there is a project that takes these changes to build a "better Vim", with the intention to merge at least some of this back, then that would generally be a good thing. But that's not what NeoVim is doing. I see a project that intends to replace Vim. And that may also have positive effects, but as a project I can't give NeoVim credit for what happens in Vim. Just like I don't give Emacs credit for ideas about what you can do with a text editor. Again, I'm talking about NeoVim as a project, not a collection of good willing contributors. And it looks like this project currently has no goal to help make Vim better. There are only side effects. If NeoVim wants to help Vim, then I'm open for ideas. Making it easy to have a patch work for both Vim and NeoVim would be a good start. I agree with Bram's approach. --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] neovim patches
On 3/7/2017 4:10 PM, Nikolay Aleksandrovich Pavlov wrote: 2017-03-08 1:14 GMT+03:00 Bram Moolenaar: Nikolay Pavlov wrote: 2017-03-05 16:56 GMT+03:00 Bram Moolenaar : Justin M. Keyes wrote: On Sat, Mar 4, 2017 at 10:10 PM, Christian Brabandt wrote: On Sa, 04 Mär 2017, Bram Moolenaar wrote: Christian Brabandt wrote: On Di, 28 Feb 2017, Bram Moolenaar wrote: - Egyptian brackets have their function as well: it means you can see more code on screen at once. Yet it does not make code harder to understand. Hardly and advantage and this is the main cause for merge problems. Having the { and } in the same column is an advantage. So this is clearly a personal preference. What is the advantage of them in the same column? More code on screen means less scrolling and more immediately visible context, this is a good and measurable metric. It is a metric, but I doubt it is the correct metric to use: for instance, so what if lots of lines can be seen at once if they are crowded and jumbled up? Bjarne Stroustrup used to use an Egyptian style based on K -- but recently adapts the Allman/BSD style: https://en.wikipedia.org/wiki/Indent_style#Variant:_Stroustrup -- one wonders what made Stroustrup switch! Perhaps he got a bigger or higher resolution monitor. - Rules for alignment/indentation of multiline expressions were written to make it easier to understand which exactly are operands/what function arguments actually belong to. Not sure what this means. Something like “+ should be indented with `a` in `(a + b)`. Though I am just describing function of another point in the style guide: it is a counter to your statement that styles are mainly personal preference, not “look Neovim has best style guide ever, because …”. I have handled tons of algebraic equations and prefer to end lines of a multi-line expression with the operator. So the argument "... make it easier to understand ..." begs the question: for whom? Not for me, thank you! --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch for quickfix.txt
On 3/6/2017 2:02 PM, Bram Moolenaar wrote: Suresh Govindachar wrote: On 3/6/2017 6:17 AM, 'Suresh Govindachar' via vim_dev wrote: [...] Thanks. Let's use backticks for commands and add a few commas: [...] Attached. --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. *** quickfix.txt.orig Mon Mar 6 20:05:58 2017 --- quickfix.txtMon Mar 6 20:11:47 2017 *** *** 43,52 compiler (see |errorformat| below). *location-list* *E776* ! A location list is similar to a quickfix list and contains a list of positions ! in files. A location list is associated with a window and each window can ! have a separate location list. A location list can be associated with only ! one window. The location list is independent of the quickfix list. When a window with a location list is split, the new window gets a copy of the location list. When there are no references to a location list, the location --- 43,55 compiler (see |errorformat| below). *location-list* *E776* ! A location list is a window-local quickfix list. You get one after commands ! like `:lvimgrep`, `:lgrep`, `:lhelpgrep`, `:lmake`, etc. which create a ! location list instead of a quickfix list as the corresponding `:vimgrep`, ! `:grep`, `:helpgrep`, `:make` do. A location list is associated with a window ! and each window can have a separate location list. A location list can be ! associated with only one window. The location list is independent of the ! quickfix list. When a window with a location list is split, the new window gets a copy of the location list. When there are no references to a location list, the location
Re: Patch for quickfix.txt
On 3/6/2017 6:17 AM, 'Suresh Govindachar' via vim_dev wrote: Attached patch to quickfix.txt is thanks to Tony Mechelynck. Updates to patch: minor wording changes; and now jumpable help tags are enclosed in ||. -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. *** quickfix.txt.orig Mon Mar 6 06:08:04 2017 --- quickfix.txtMon Mar 6 07:04:40 2017 *** *** 43,52 compiler (see |errorformat| below). *location-list* *E776* ! A location list is similar to a quickfix list and contains a list of positions ! in files. A location list is associated with a window and each window can ! have a separate location list. A location list can be associated with only ! one window. The location list is independent of the quickfix list. When a window with a location list is split, the new window gets a copy of the location list. When there are no references to a location list, the location --- 43,54 compiler (see |errorformat| below). *location-list* *E776* ! A location list is a window-local quickfix list. You get one after commands ! like |:lvimgrep| |:lgrep| |:lhelpgrep| |:lmake| etc. which create a location ! list instead of a quickfix list as the corresponding |:vimgrep| |:grep| ! |:helpgrep| |:make| do. A location list is associated with a window and each ! window can have a separate location list. A location list can be associated ! with only one window. The location list is independent of the quickfix list. When a window with a location list is split, the new window gets a copy of the location list. When there are no references to a location list, the location
Patch for quickfix.txt
Attached patch to quickfix.txt is thanks to Tony Mechelynck. --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. *** quickfix.txt.orig Mon Mar 6 06:08:04 2017 --- quickfix.txtMon Mar 6 06:09:25 2017 *** *** 43,50 compiler (see |errorformat| below). *location-list* *E776* ! A location list is similar to a quickfix list and contains a list of positions ! in files. A location list is associated with a window and each window can have a separate location list. A location list can be associated with only one window. The location list is independent of the quickfix list. --- 43,53 compiler (see |errorformat| below). *location-list* *E776* ! A location list is a window-local quickfix list. You get one after ! commands like :lvimgrep :lgrep :lhelpgrep :lmake etc. which ! create a location list instead of a quickfix list like the ! corresponding :vimgrep :grep :helpgrep :make etc. do. ! A location list is associated with a window and each window can have a separate location list. A location list can be associated with only one window. The location list is independent of the quickfix list.
Re: A nice mapping for the Kings' Day (or Old-Style Christmas, or whatever)
On 1/7/2016 2:06 PM, Tony Mechelynck wrote: This assumes 'nocompatible' if exists(':map') == 2 && exists(':smile') == 2 nnoremap :intexe "smi" endif Have fun! > ... I checked gvim/vim on Windows and Ubuntu (14.x), and while both had 'nocompatible' and ':map', neither has ':smile'. In fact, I have been unable to find (via vim's help and via googling) what in the world ':smile' is all about! So what's ':smile' and where can I find a vim that meets the requirements for "having fun"? Thanks, --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ENABLE_WINDOW_INPUT flag
On 2/3/2014 10:25 PM, John Little wrote: On Tuesday, February 4, 2014 4:26:07 PM UTC+13, Suresh Govindachar wrote: I am told that ENABLE_WINDOW_INPUT is disabled for xterm. Why is this being done? Is that the question you meant to ask? ENABLE_WINDOW_INPUT is some win32 API flag; it's not used with xterm. Or are you bumping your report: https://groups.google.com/forum/?hl=en#!topic/vim_dev/ZfEpoxL-j7w I asked the question I meant to ask. However, I came across the information about ENABLE_WINDOW_INPUT while investigating why resizing worked somewhat when term was win32 and did not work when term was xterm via ConEmu on Windows. I suspect ConEmu currently communicates changes in sizes the same way win32 console does rather that in some xterm protocol way -- if so, the information from ConEmu about changed sizes is not getting to Vim since ENABLE_WINDOW_INPUT is disabled even on Windows when term is xterm. On Windows, when running Vim inside ConEmu and term is xterm, and ENABLE_WINDOW_INPUT is disabled, how does Vim expect to be informed about changes in sizes? Also, what would happen if ENABLE_WINDOW_INPUT was always true on Windows irrespective of the value of term? --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Bug: vim can contract but not expand
Hello, Steps to reproduce bug on Windows 7, 64 bit, Official big version of vim.exe: 1) Create a file, foo.vim, as follows: set laststatus=2 augroup ReSizingReporter autocmd VimResized * echomsg c: columns l: lines augroup END 2) Start cmd.exe. Right-click on top bar and select Properties. Select Layout tab; make both Screen Buffer Size and Window Size to be equal and to be, say, width of 96 and height of 32. 3) Start vim.exe -u foo.vim --noplugin 4) Right click on top bar, select Properties and make _only_ Screen Buffer Size smaller, say, width 64 and height 24. 5) Issue command :messages and verify that Vim has reacted to change in size. 6) Exit vim. Repeat steps (2 and 3). 7) Right click on top bar, select Properties and make _only_ Screen Buffer Size _larger_, say, width 128 and height 36. 8) Observe that vim is now confused. :messages shows nothing. Click and drag corner of window so that scroll bars disappear. Right click on top bar, select Properties and observe that Window Size now equals Screen Buffer Size. Still :messages shows nothing, and vim is confused. 9) Issue command :set columns 128 and :set lines 36 -- vim has become OK again. So vim reacts properly to contraction of window but not to expansion of window. --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ENABLE_WINDOW_INPUT flag
Hello, I am told that ENABLE_WINDOW_INPUT is disabled for xterm. Why is this being done? Thanks, --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Bulk] Re: NOlazyredraw and need for Ctrl-l (or :redraw!): provide any clue for bug with vim inside ConEmu?
On 1/16/2014 10:24 AM, Maximus ConEmu wrote: On Thursday, January 16, 2014 10:05:58 AM UTC+4, Suresh Govindachar wrote: When running vim inside ConEmu, although lazyredraw is OFF (nolazydraw), I still find the need to hit Ctrl-L or execute :redraw! (with shriek) to clear up the screen that has been messed-up by some bug with using Vim inside ConEmu ( http://code.google.com/p/conemu-maximus5/issues/detail?id=1336 ). Issue 1336 is still awaiting yours confirmation. You have not received notification? There was some fixes in ConEmu ANSI processor. Yesterday, I tried 140114a but the issue is still present. Over the weekend, I plan to provide a more detailed response at the bug-report site. Thanks, --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
NOlazyredraw and need for Ctrl-l (or :redraw!): provide any clue for bug with vim inside ConEmu?
Hello, When running vim inside ConEmu, although lazyredraw is OFF (nolazydraw), I still find the need to hit Ctrl-L or execute :redraw! (with shriek) to clear up the screen that has been messed-up by some bug with using Vim inside ConEmu ( http://code.google.com/p/conemu-maximus5/issues/detail?id=1336 ). Does the observation of the need for Ctrl-L even with NOlazyredraw provide a clue as to what bug with using vim inside ConEmu might be? Thanks, --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Feature request: flag to 'complete' so that i_Ctrl-N ignores remote buffers
On 11/13/2013 6:03 AM, Christian Brabandt wrote: On Tue, November 12, 2013 16:53, Ben Fritz wrote: On Monday, November 11, 2013 10:45:15 PM UTC-6, Suresh Govindachar wrote: Hello, Please consider providing the feature whereby i_Ctrl-N would ignore buffers whose name begins with \\machine_name\ and machine_name is a remote machine (Microsoft Uniform Naming Convention (UNC)). I think what you're really asking is for a way to exclude buffers or files from being processed by insert-mode completion, if you know scanning them will be slow. This could be true for very large file, or for files on a network share, or files that require reading with autocmds to unzip them or something. I support such an option. I like keeping 'path' fairly large for searching with :find for a file, but this makes insert completion very slow if I allow it to search in included files. Previously when we were using ClearCase on my team, EVERY insert completion that scanned other files was slow, because the ClearCase dynamic view mapped network drive is painfully slow. I had to turn off most of the completion functions. I'd certainly use a filter to remove specific directories from insert completion scanning, were it available. So this would mean, having a new buffer local option like 'completebufignore' that is off by default and could be set to ignore the current buffer from being processed for completion? It's the other way around -- most of the time I want to search the current buffer and most of the other buffers -- but want to exclude certain remote buffers. Bram, what are youre thoughts regarding adding yet another option? Other suggestions? I was thinking one could enhance the existing 'complete' with include and exclude patterns: set complete+=/include_this_pattern,!/exclude_this_pattern but I really do not know the source code and so have no idea how viable the above scheme is. --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Feature request: flag to 'complete' so that i_Ctrl-N ignores remote buffers
Hello, Please consider providing the feature whereby i_Ctrl-N would ignore buffers whose name begins with \\machine_name\ and machine_name is a remote machine (Microsoft Uniform Naming Convention (UNC)). Thanks, --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Patch 7.3.1209
On 6/16/2013 7:14 AM, Bram Moolenaar wrote: Patch 7.3.1209 Problem:No completion for :tabdo. Solution: Add tabdo to the list of modifiers. (Dominique Pelle) Files:src/ex_docmd.c In April 2013, I had reported a bug in command line completion: Command line completion doesn't use . and ,, in path: Bug?. Then Nazri Ramliy provided a patch for it. I verified the patch to src/misc1.c on April 21 (but did not verify the patches to files src/testdir/test73.in and src/testdir/test73.ok). Any plans to include this patch or any other fix for the bug? Thanks, --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Plans for Vim 7.4
--- On Wed, 5/8/13, Christian J. Robinson hept...@gmail.com wrote: From: Christian J. Robinson hept...@gmail.com Subject: Re: Plans for Vim 7.4 To: vim_dev@googlegroups.com Date: Wednesday, May 8, 2013, 9:01 PM [Replied only to the Vim Developers' list.] On Thu, 9 May 2013, Bram Moolenaar wrote: it's time for Vim 7.4! [...] 1. Include the Python patches that ZyX has created. This improves the Vim API from the Python interface. I know you cannot possibly be expected to add similar support for the other scripting interfaces yourself, but I am hoping someone is willing to add some of these extras to the Perl interface. What are these extras Christian is referring to? -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Command line completion doesn't use . and ,, in path: Bug?
On 4/14/2013 10:56 PM, Nazri Ramliy wrote: Hi Suresh! On Mon, Apr 15, 2013 at 10:22 AM, Suresh Govindachar sgovindac...@yahoo.com wrote: Hitting tab after entering a partial argument to :find will offer suggestions for completing the command line by searching inside non-trivial components of the 'path' -- but it does not search in . and in ,, components of the path. Here's what I see: On vim's command line, the following finds the possible completions :find ./foo/blah/blee[hit the tab key] but the following (without the leading ./) will not: :find foo/blah/blee[hit the tab key] I'm trying to reproduce the problem but couldn't: My setup: As indicated below, your setup is different from mine: d:\foodir /s (i leave out the . and .. entries to slim down the lines below) Directory of D:\foo 15/04/2013 01:41 PM 9 foo.txt 15/04/2013 01:41 PM10 food.txt 15/04/2013 01:32 PMDIR opt Directory of D:\foo\opt 15/04/2013 01:44 PMDIR vim Directory of D:\foo\opt\vim 15/04/2013 01:32 PM11 700_vimrc 15/04/2013 01:33 PM10 fish.txt 15/04/2013 01:33 PM12 finger.txt d:\foogvim -u NONE -U NONE Start gvim from d: :set cp wildchar=Tab wildmode=list:longest,full :set path=.,,d:/foo/opt/vim,d:/foo/opt/vim/** My c:\opt is not below the pwd. Anyway, for the test, leave path at the default value of .,,. :pwd D:\foo When starting from d:, :pwd will show d:\ Now doing In gvim, open file d:\foo\opt\vim\fish.txt Then try the following :find foo[hit tab] and :find *foo*[hit tab] Thanks, --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Command line completion doesn't use . and ,, in path: Bug?
Hello, Hitting tab after entering a partial argument to :find will offer suggestions for completing the command line by searching inside non-trivial components of the 'path' -- but it does not search in . and in ,, components of the path. Here's what I see: On vim's command line, the following finds the possible completions :find ./foo/blah/blee[hit the tab key] but the following (without the leading ./) will not: :find foo/blah/blee[hit the tab key] Some more examples: verbose set path? path=.,,c:/opt/vim,c:/opt/vim/** Last set from C:\opt\vim\700_vimrc Hitting tab after :find 700 does find the above 700_vimrc file. Also, :find *vimrc*[hit tab] finds lots of matches. But :find *foo*[hit tab] does not find a foo that exists in the current directory. My other settings: verbose set wildchar? wildchar=Tab Last set from C:\opt\vim\vim73\runtime\vimrc_example.vim verbose set wildmode? wildmode=list:longest,full Last set from C:\opt\vim\700_vimrc It has been this way with various versions of vim; my current vim is: VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 21 2013 18:17:56) MS-Windows 64-bit GUI version with OLE support Included patches: 1-831 Thanks, --Suresh -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
vimgrep and Vim's connection with google
Hello, Tools such as tags, cscope, global, idutils etc. for spelunking code essentially involve creating an index of the files in the project and using this index. Tools like vim's :vimgrep work harder without the benefit of an index. Some of the tools are restricted to C code only (with maybe some kludged support for C++). And people continue to work at making new indexers (eg, http://silentbob.sourceforge.net/). Anyway, given Vim's connection to google, I am wondering if Bram has ideas for an indexer that would work nicely with Vim and help spelunk code in various languages. If there aren't already any on-going project with such a goal, Bram please consider proposing such projects. Thanks, --Suresh -- 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
Why can't CR be eaten while concealing?
Hello, When a string is concealed, characters in the string along each line are replaced by nothing; but any CRs in the string remain as CRs. Why is the design this way? If it is possible to make conceal remove any CRs in the string being concealed, please consider offering this feature. Thanks, --Suresh -- 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
RE: Building for Windows 7 64 bit with 64 bit dynamic perl
A short time ago, I wrote: At present, I am downloading vim sources (using mercurial) with the view to using MinGW 64 to build for Windows 7 64 bit, huge version with OLE and with support for dynamic perl 64 bit version 5.12. I am planning to use Make_ming.mak. Are there any know issues with this attempt? I looked inside Make_ming.mak -- it appears to be hard-coded for 32 bit windows. Has anyone had success with such an attempt? Please do let me know if you have successfully built a 64 bit vim for Windows 7 64 bit with support for 64 bit perl 5.12. Thanks, --Suresh -- 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
Build error about --with-tlib
Hello, How would I fix the following error message I get when tying to build vim on fedora core 8 linux (#1 SMP Thu Dec 18 19:19:45 EST 2008 i686 i686 i386 GNU/Linux), using the vim72 sources?: checking whether time.h and sys/time.h may both be included... yes checking for ino_t... yes checking for dev_t... yes checking for rlim_t... yes checking for stack_t... yes checking whether stack_t has an ss_base field... no checking --with-tlib argument... empty: automatic terminal library selection checking for tgetent in -lncurses... no checking for tgetent in -ltermlib... no checking for tgetent in -ltermcap... no checking for tgetent in -lcurses... no no terminal library found checking for tgetent()... configure: error: NOT FOUND! You need to install a terminal library; for example ncurses. Or specify the name of the library with --with-tlib. make[1]: *** [config] Error 1 make[1]: Leaving directory `/h/sgovinda/tmp/vim72/src' make: *** [first] Error 2 Thanks, --Suresh -- 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
RE: Build error about --with-tlib
On the vim user mailing list, Benjamin R. Haskell explained the issue: On Sat, 27 Feb 2010, Suresh Govindachar wrote: [...] I tried 3 ways to install vim-with-everything on Fedora Core 8, but failed: Attempt 1) vim-7.2.tar.bz2 - typing make resulted in the following error: [...] checking for tgetent()... configure: error: NOT FOUND! You need to install a terminal library; for example ncurses. Or specify the name of the library with --with-tlib. Generally, to compile software on RPM-based distributions, you need to install '-dev' or '-devel' packages for things that are normally installed as binaries. So, you might have 'curses' or 'ncurses' installed, but you also need 'curses-devel' or 'ncurses-dev' (I don't know the correct name). You'll probably need several such packages. [...] -- 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
RE: Installing Vim on Vista (Was: )
There is a known issue with things working on Vista having to do the _access() function. For example, the application gcc uses _access() to find other tools such as cc1.exe and the usual gcc fails on Vista -- the usual gcc needs to be patched to work on Vista. If VIM uses _access() to find things, vim is likely to fail too. My very high level understanding: In older MSVCRT, passing X_OK to _access was the same as passing F_OK. But in Vista, passing X_OK returns the error invalid param value. --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
How to tell vim about new shell and new console (terminal)?
Here's what MicroSoft is up to for console/terminal: http://www.powershell.com/plus/ Weird that that thing seems to still have only 16 colors! It is possible to try out PowerShell (a shell, not a console/terminal) today. Commands in PowerShell do not move text data via pipes; rather they move entire objects. Question: Any plans for vim and gvim to interact with this shell and console? --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: patch to if_perl.xs
The terser version looks OK to me. --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Buffer names -- efficiency (or inefficiency bug)
Bram asked for a reproduciable example: Version: VIM - Vi IMproved 7.1 (2007 May 12, compiled May 12 2007 14:19:39) MS-Windows 32 bit GUI version with OLE support Compiled by [EMAIL PROTECTED] Big version with GUI. Features included (+) or not (-): Steps: a) c:\opt\vim\vim71.bram\gvim.exe --noplugin b) :find c:\home\suresh\_doskey_macros :find c:\home\suresh\\_doskey_macros :find c:\home\\suresh\\_doskey_macros c) :ls shows 1 c:\home\suresh\_doskey_macros line 1 2 #c:\home\suresh\\_doskey_macros line 1 3 %a c:\home\\suresh\\_doskey_macros line 1 Can be repeated with a 7.1 version that has 100 patches. --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: svn/cvs checkout hangs
Edward L. Fox wrote: svn co https://vim.svn.sourceforge.net/svnroot/vim/vim7 vim7_svn Well, although Bram recommended to checkout from /svnroot/vim/vim7, I'm regretful to say, you may encounter a circumstance that all files in your svn working directory being deleted after you run svn up. Such situation might happen in a probability of 1/500,000. What is the nature of the problem? If there is something wrong with co from that location, why doesn't update delete files _all_ the time? Yes, quite slim, but it indeed exists. So... Just do it at your own risk. :-) I suggest that checking out from https://vim.svn.sourceforge.net/svnroot/vim/branches/vim71/. Svn says that that location does not exist: c:\opt\svn\svn-win32-1.4.4\bin\svn.exe co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim71/. foo svn: URL 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim71' doesn't exist Same error in all four cases of with or without foo and with or without trailing /. --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch for if_perl.xs
Patch for if_perl.xs attached below. --Suresh *** vim7\src\if_perl.xs Tue Sep 04 17:12:39 2007 --- patched\if_perl.xsTue Sep 04 16:28:12 2007 *** *** 40,45 --- 40,67 #define PERL_SUBVERSION SUBVERSION #endif + /* + * Quoting Jan Dubois of Active State: + * + *ActivePerl build 822 still identifies itself as 5.8.8 but already + *contains many of the changes from the upcoming Perl 5.8.9 release. + * + * The changes include addition of two symbols (Perl_sv_2iv_flags, + * Perl_newXS_flags) introduced in not present in earlier releases. + * + * Jan Dubois suggested the following guarding scheme: + * + */ + #if (ACTIVEPERL_VERSION = 822) + # define PERL589_OR_LATER + #endif + #if (PERL_REVISION == 5) (PERL_VERSION == 8) (PERL_SUBVERSION = 9) + # define PERL589_OR_LATER + #endif + #if (PERL_REVISION == 5) (PERL_VERSION = 10) + # define PERL589_OR_LATER + #endif + #ifndef pTHX #define pTHX void #define pTHX_ *** *** 109,114 --- 131,140 # else # define Perl_sv_catpvn dll_Perl_sv_catpvn # endif + #ifdef PERL589_OR_LATER + # define Perl_sv_2iv_flagsdll_Perl_sv_2iv_flags + # define Perl_newXS_flags dll_Perl_newXS_flags + #endif # define Perl_sv_free dll_Perl_sv_free # define Perl_sv_isa dll_Perl_sv_isa # define Perl_sv_magic dll_Perl_sv_magic *** *** 192,197 --- 218,227 #else static void (*Perl_sv_catpvn)(pTHX_ SV*, const char*, STRLEN); #endif + #ifdef PERL589_OR_LATER + static IV (*Perl_sv_2iv_flags)(pTHX_ SV* sv, I32 flags); + static CV * (*Perl_newXS_flags)(pTHX_ const char *name, XSUBADDR_t subaddr, const char *const filename, const char *const proto, U32 flags); + #endif static void (*Perl_sv_free)(pTHX_ SV*); static int (*Perl_sv_isa)(pTHX_ SV*, const char*); static void (*Perl_sv_magic)(pTHX_ SV*, SV*, int, const char*, I32); *** *** 266,271 --- 296,305 {Perl_sv_2pv_nolen, (PERL_PROC*)Perl_sv_2pv_nolen}, #else {Perl_sv_2pv, (PERL_PROC*)Perl_sv_2pv}, + #endif + #ifdef PERL589_OR_LATER + {Perl_sv_2iv_flags, (PERL_PROC*)Perl_sv_2iv_flags}, + {Perl_newXS_flags, (PERL_PROC*)Perl_newXS_flags}, #endif {Perl_sv_bless, (PERL_PROC*)Perl_sv_bless}, #if (PERL_REVISION == 5) (PERL_VERSION = 8) --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Build broken -- Undefined references -- MinGW, vim with perl
.dll gurus, Latest response from Jan Dubois of ActiveState: On Fri, 24 Aug 2007, Suresh Govindachar wrote: Sisyphus suggested linking with C:/opt/perl/lib/CORE/perl58.lib (which does have the symbols in it) in the command that creates if_perl.o and/or in the command that builds gvim.exe (which is also the command that reports the missing references). But the build is supposed to use the library dynamically, rather than be statically linked. So perl58.dll must tell the linker that it will resolve the missing references at run time. Perhaps although ActiveState added code for the references, they are not exposing them to the linker for dynamic use via perl58.dll? Or is everything in a dll automatically visible? Perl_sv_2iv_flags is exported from perl58.dll. This symbols is being used by virtually every Perl module containing XS code because the SvIV() macro will expand into a call to it: [in sv.h] #define SvIV(sv) (SvIOK(sv) ? SvIVX(sv) : sv_2iv(sv)) ... #define sv_2iv(sv) sv_2iv_flags(sv, SV_GMAGIC) --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Build broken -- Undefined references -- MinGW, vim with perl
Earlier, I asked the dll gurus, Latest response from Jan Dubois of ActiveState: On Fri, 24 Aug 2007, Suresh Govindachar wrote: Sisyphus suggested linking with C:/opt/perl/lib/CORE/perl58.lib (which does have the symbols in it) in the command that creates if_perl.o and/or in the command that builds gvim.exe (which is also the command that reports the missing references). But the build is supposed to use the library dynamically, rather than be statically linked. So perl58.dll must tell the linker that it will resolve the missing references at run time. Perhaps although ActiveState added code for the references, they are not exposing them to the linker for dynamic use via perl58.dll? Or is everything in a dll automatically visible? Perl_sv_2iv_flags is exported from perl58.dll. This symbols is being used by virtually every Perl module containing XS code because the SvIV() macro will expand into a call to it: [in sv.h] #define SvIV(sv) (SvIOK(sv) ? SvIVX(sv) : sv_2iv(sv)) ... #define sv_2iv(sv) sv_2iv_flags(sv, SV_GMAGIC) Note: grep -rl Perl_sv_2iv_flags C:\opt\perl/lib/Core results in: C:\opt\perl/lib/Core/embed.h C:\opt\perl/lib/Core/perl58.lib C:\opt\perl/lib/Core/proto.h So added -lperl58 to the command that generates if_perl.o and to the command that generates gvim.exe. The first command reported: gcc: -lperl58: linker input file unused because linking not done The second command resulted in the same undefined reference error. Just to be sure, I added -lblah to the second command, and got the new error message: c:\opt\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lblah --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Build broken -- Undefined references -- MinGW, vim with perl
Solved with help from Brian Dessent on the MinGW mailing list. Add -lperl58 at the very end (location matters) of the last command. --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Shortcoming of if_perl.xs
cc: Sven Verdoolaege -- where are you? Jan Dubois of ActiveState points out an issue with if_perl.xs: Jan Dubois wrote: On Mon, 27 Aug 2007, Suresh Govindachar wrote: So ActiveState is exporting Perl_sv_2iv_flags and Perl_newXS_flags in a way that is different from the way they export other symbols. Nope, this is all incorrect. I've now downloaded the vim sources to see what is really going on: The src/if_perl.xs file contains code to redefine all Perl functions it assumes it uses to wrapper names, and then looks up the real functions at runtime. That means that this file is specific to the Perl version used to compile it and will need to be updated for Perl 5.8.9. See for example: # if (PERL_REVISION == 5) (PERL_VERSION = 8) # define Perl_sv_2pv_flags dll_Perl_sv_2pv_flags # define Perl_sv_2pv_nolen dll_Perl_sv_2pv_nolen # else # define Perl_sv_2pv dll_Perl_sv_2pv # endif ... #if (PERL_REVISION == 5) (PERL_VERSION = 8) static char* (*Perl_sv_2pv_flags)(pTHX_ SV*, STRLEN*, I32); static char* (*Perl_sv_2pv_nolen)(pTHX_ SV*); #else static char* (*Perl_sv_2pv)(pTHX_ SV*, STRLEN*); #endif ... Similar code will be needed for sv_2iv_flags() and any other new symbol. It is a bit awkward to do this for ActivePerl 822, as it identifies itself as 5.8.8 because 5.8.9 has not been released yet, so we don't know which additional features will still be added. But internally AP822 is probably closer to what will be 5.8.9 than to 5.8.8. Anyways, the problem is that if_perl.xs is coupled pretty tightly to the Perl internals and needs updating whenever the internals change. --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Build broken -- Undefined references -- MinGW, vim with perl
Hello, Attached below is the result of issuing the following command (command has been written in multiple lines to make it easy to read): C:\home\suresh\develop\vim\vim7\src c:\opt\mingw\bin\mingw32-make.exe -f Make_ming.mak FEATURES=HUGE DEBUG=no GUI=yes OLE=yes PERL=C:/opt/perl PERL_VER=58 CC=c:/opt/MinGW/bin/gcc -Ic:/opt/MinGW/include -Lc:/opt/MinGW/lib Versions: VIM Source: Output of the update command C:\home\suresh\develop\vim\vim7 c:\opt\svn\svn-win32-1.4.4\bin\svn update is At revision 482. MinGW: c:\opt\MinGW\bin\mingw32-make.exe --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 perl: C:\home\suresh\develop\vim\vim7perl --version This is perl, v5.8.8 built for MSWin32-x86-multi-thread (with 18 registered patches, see perl -V for more detail) Copyright 1987-2007, Larry Wall Binary build 822 [280952] provided by ActiveState http://www.ActiveState.com Built Jul 31 2007 19:34:48 The Error Message: c:/opt/MinGW/bin/gcc -Ic:/opt/MinGW/include -Lc:/opt/MinGW/lib -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -D HAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall - IC:/opt/perl/lib/Core -DFEAT_PERL -LC:/opt/perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-fra me-pointer -freg-struct-return -s -mwindows -o gvim.exe gobj/buffer.o gobj/charset.o gobj/diff.o gobj/digraph.o gobj/edi t.o gobj/eval.o gobj/ex_cmds.o gobj/ex_cmds2.o gobj/ex_docmd.o gobj/ex_eval.o gobj/ex_getln.o gobj/fileio.o gobj/fold.o gobj/getchar.o gobj/hardcopy.o gobj/hashtab.o gobj/main.o gobj/mark.o gobj/memfile.o gobj/memline.o gobj/menu.o gobj/mes sage.o gobj/misc1.o gobj/misc2.o gobj/move.o gobj/mbyte.o gobj/normal.o gobj/ops.o gobj/option.o gobj/os_win32.o gobj/os _mswin.o gobj/pathdef.o gobj/popupmnu.o gobj/quickfix.o gobj/regexp.o gobj/screen.o gobj/search.o gobj/spell.o gobj/synt ax.o gobj/tag.o gobj/term.o gobj/ui.o gobj/undo.o gobj/version.o gobj/vimrc.o gobj/window.o gobj/if_perl.o gobj/if_cscop e.o gobj/netbeans.o gobj/gui.o gobj/gui_w32.o gobj/gui_beval.o gobj/os_w32exe.o gobj/if_ole.o -lkernel32 -luser32 -lgdi3 2 -ladvapi32 -lcomdlg32 -lcomctl32 -lversion -lwsock32 -loleaut32 -lstdc++ -lole32 -luuid gobj/buffer.o:buffer.c:(.text+0x117f): undefined reference to `perl_buf_free' gobj/buffer.o:buffer.c:(.text+0x207e): undefined reference to `perl_buf_free' gobj/eval.o:eval.c:(.text+0x4359): undefined reference to `perl_enabled' gobj/ex_docmd.o:ex_docmd.c:(.data+0xe5c): undefined reference to `ex_perl' gobj/ex_docmd.o:ex_docmd.c:(.data+0xe68): undefined reference to `ex_perldo' gobj/main.o:main.c:(.text+0x614): undefined reference to `perl_end' gobj/window.o:window.c:(.text+0x108f): undefined reference to `perl_win_free' collect2: ld returned 1 exit status mingw32-make: *** [gvim.exe] Error 1 C:\home\suresh\develop\vim Any idea what's happening? Thanks, --Suresh Full log: C:\home\suresh\develop\vim\vim7\srcc:\opt\mingw\bin\mingw32-make.exe -f Make_ming.mak FEATURES=HUGE DEBUG=no GUI=yes OLE=yes PERL=C:/opt/perl PERL_VER=58 CC=c:/opt/MinGW/bin/gcc -Ic:/opt/MinGW/include -Lc:/opt/MinGW/lib mkdir gobj c:/opt/MinGW/bin/gcc -Ic:/opt/MinGW/include -Lc:/opt/MinGW/lib -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_IN TG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wal l -IC:/opt/perl/lib/Core -DFEAT_PERL -LC:/opt/perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit- frame-pointer -freg-struct-return -s buffer.c -o gobj/buffer.o c:/opt/MinGW/bin/gcc -Ic:/opt/MinGW/include -Lc:/opt/MinGW/lib -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_IN TG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wal l -IC:/opt/perl/lib/Core -DFEAT_PERL -LC:/opt/perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit- frame-pointer
Make clean does not remove if_perl.c
Hello, make -f Make_ming.mak clean does not remove if_perl.c Thanks, --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Build broken -- Undefined references -- MinGW, vim with perl
[Yongwei Wu drew attention to if_perl.c] Make clean was not removing an earlier, bad if_perl.c. In the output I reported, if_perl.c was size 0. I manually deleted if_perl.c, and now get other errors. Before telling what the errors were, here's more background info: It is a new hard-drive -- everything (tools, utilities, sources etc.) is a fresh install from the internet. I _can_ use perl with Bram's build of vim 7.1 I know that the svn location for the sources was changed; is the address given at vim.org the new address or the old one? svn co https://vim.svn.sourceforge.net/svnroot/vim/vim7 I am able to build gvim with MinGW GCC 3.4.5 without problems. I tried with: The gcc version with the latest MinGW is (gcc --version) gcc (GCC) 3.4.2 (mingw-special) The command I used was: C:\home\suresh\develop\vim\vim7\src mingw32-make.exe -f Make_ming.mak FEATURES=HUGE GUI=yes OLE=yes PERL=C:\opt\perl PERL_VER=58 Could the issue be with the latest release of perl (v5.8.8 built for MSWin32-x86-multi-threade with 18 registered patches)? But this perl works with Bram's build of vim 7.1. The error message is now (entire log is appended below): gobj/if_perl.o:if_perl.c:(.text+0x1c1f): undefined reference to `Perl_sv_2iv_flags' Thanks, --Suresh C:\home\suresh\develop\vim\vim7\srcmingw32-make.exe -f Make_ming.mak FEATURES=HUGE GUI=yes OLE=yes PERL=C:\opt\perl PE RL_VER=58 mkdir gobj gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H - DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE _IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s buffer.c -o gobj/buffer .o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H - DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE _IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s charset.c -o gobj/chars et.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H - DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE _IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s diff.c -o gobj/diff.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H - DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE _IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s digraph.c -o gobj/digra ph.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H - DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE _IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s edit.c -o gobj/edit.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H - DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE _IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s eval.c -o gobj/eval.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H - DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE _IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s ex_cmds.c -o gobj/ex_cm ds.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400
RE: Build broken -- Undefined references -- MinGW, vim with perl
Tony suggested looking at other builds -- however, I have been getting sources and building by own vim for over a year. My hard-drive crashed; have a new hard-drive. I am doing the exact same thing I used to do -- expcept I now have the latest release of ActiveState perl and MinGW. ActiveState changed the directory structure for this release, but I don't think that is the cause of the problem. Have attached a cleaner looking log below. --Suresh Versions: Perl v5.8.8 built for MSWin32-x86-multi-thread (with 18 registered patches). Built Jul 31 2007 19:34:48. I tried a few perl commands from inside the pre-built version of vim 7.1 with dynamic perl support and the commands worked. VIM Source: Output of the update command C:\home\suresh\develop\vim\vim7 c:\opt\svn\svn-win32-1.4.4\bin\svn update is At revision 482. MinGW: c:\opt\MinGW\bin\mingw32-make.exe --version GNU Make 3.81 gcc --version reports: gcc (GCC) 3.4.2 (mingw-special) C:\home\suresh\develop\vim\vim7\srcmingw32-make.exe -f Make_ming.mak FEATURES=HUGE GUI=yes OLE=yes PERL=C:\opt\perl PERL_VER=58 mkdir gobj gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s buffer.c -o gobj/buffer.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s charset.c -o gobj/charset.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s diff.c -o gobj/diff.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s digraph.c -o gobj/digraph.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s edit.c -o gobj/edit.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s eval.c -o gobj/eval.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -IC:\opt\perl/lib/Core -DFEAT_PERL -LC:\opt\perl/lib/Core -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl58.dll\ -O3 -fomit-frame-pointer -freg-struct-return -s ex_cmds.c -o gobj/ex_cmds.o gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_HUGE -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_OLE -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w
BadSpell not grouped properly?
Hello, Invoking he following command -- when N is 0 or 1: :echo synIDattr(synID(line(.), col(.), N), name) when the cursor is on the badly spelled word ontiger int foo; /* this is an ontiger */ results in the same answer cComment. Should it not respond as BadSpell? I contacted the author of SyntaxAttr.vim Gary Holloway. http://www.vim.org/scripts/script.php?script_id=383 (His plugin reports cComment-Comment.) He speculated that the BadSpell group needs to be contained in the cComment group; something like: syn match BadSpell ... contained containedin=cComment For the example given above, what needs to be done (or which command needs to be invoked) to get the response BadSpell? Thanks, --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: dynamic programming for gq formatting
Ismo Puustinen mentioned: I recently wrote an implementation of the optimal line breaking algorithm (in Ruby). If you are interested, the file is located here, with a small piece of test code at the end: http://lissujaismo.net/rbpar/rbpar_engine.rb You can run the test code by saying ruby rbpar_engine.rb. The library is actually part of a (yet unreleased) email text processing framework that I've been writing for Vim and other plain text editors. I think it shouldn't be too difficult to use Vim Ruby bindings to run the algorithm for a range of text lines, but I haven't looked at that yet. One possible problem could be maintaining the cursor position. Attached below are a few ways of using the Perl module Text::Autoformat to format text in Vim (warning: the email transport mechanism is likely to wrap some long lines). I suspect these techniques can be adapted for a ruby module. Please provide me a precise reference to the optimal line breaking algorithm you mention. Thanks, --Suresh Some mappings related to use of Text::Autoformat: Although there are several maps below, I almost exclusively use maps related to the '=' command. Note how textwidth and filetype (mail) options are used at the time of invocation of the command! Using external (rather than embedded) perl: -- Via the ={motion} command: nnoremap = :execute 'setlocal equalprg=perl\ \-MText::Autoformat\ -e\ \\{autoformat{all=1'. \',\ right=' \.(tw?tw:72). \',\ mail='. \(ft=='mail'?1:0). \'};}\' \cr= Shortcut for formatting the range .,$: nnoremap F3 :execute '.,$!perl -MText::Autoformat -e \ {autoformat{all=1, right=' . \ (tw ? tw : 72) . \ ', mail='. \ (ft=='mail'?1:0). \ '};}'cr Using embedded perl: --- if(has('perl')) command! -range=% Format : \ perl { \ use Text::Autoformat; \ my $n_line1 = VIM::Eval('line1'); \ my $n_line2 = VIM::Eval('line2'); \ my $foo= join \n, $curbuf-Get($n_line1 .. $n_line2); \ my $tw=VIM::Eval('textwidth'); \ $tw or $tw = 72; \ my $ft=VIM::Eval('filetype'); \ $ft = ($ft eq 'mail') ? 1 : 0; \ my $formatted = autoformat($foo, {right=$tw, all=1, mail=$ft}); \ my @formatted_lines = split '\n', $formatted; \ $curbuf-Delete($n_line1, $n_line2); \ $curbuf-Append($n_line1-1, @formatted_lines, ''); \ } Shortcut for formatting the paragraph around the cursor: nnoremap =p {}:'`,Formatcr:silent!wcr nnoremap =p {}:'`,Formatcr Format the stuff over the _previous_ motion: nnoremap F4 :'`,Formatcryesc:silent!wcr nnoremap F4 :'`,Formatcryesc Format the visual selection: vnoremap F4 :Formatcr:silent!wcr vnoremap F4 :Formatcr endif --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Pseudo-verbosity of was set in error handler
Hello, The following response to :verbose set foo? was set in error handler is not informative. To be informative, the message should mention something to indicate who/what/when/where was trying to set the illegal value. For example, I have been using a valid statusline set in my vimrc for a long time. A short time ago, it suddenly got set to nothing. While I now know that the error handler set it to nothing, I have no clue as to who/what/when/where was trying to set it to a bad value! --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: there's undojoin -- how about dotjoin?
Tony asked: Bram Moolenaar wrote: How about using CTRL-G CTRL-O for going to Normal mode without breaking the current Insert in two? It would only work when the cursor didn't move and the text isn't changed. I don't find Ctrl-G Ctrl-O under :help ins-special-special (or anywhere in Insert mode). Maybe you mean Ctrl-\ Ctrl-O ? Bram is proposing a new insert mode command Ctrl-G Ctrl-O that is like the current insert mode command Ctrl-O except that the proposed command will preserve the . command in those situations wherein the what's done after Ctrol-O does not move the cursor and does not change any text. --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: Working of [I
Earlier, I asked: I am not curious about how [I finds the files to look into. What I would like to know is what [I does inside each file it decides to look into. Am I correct that the [I does not use the tags file? If it uses the tags file, how? Once inside a file, how is what [I does different from what a /search would do? I realize that [I summarizes and displays the results of the search, but is there any difference in the searching method? More questions: Can one extend [I (and related commands) to search, perhaps using vimgrep, not just in the include files but in all files that show up in the tags file (which would be all files in the project)? I find that [I is slow -- is the slowness in having to decide on which files to search or in the actual searching? Given a file, how does the performance of the searching algorithm used by [I compare to that used by vimgrep? Thanks, --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: patch 7.1.068
Bram Moolenaar wrote: The 'equalalways' option has the intention to spread out the available space, so that when you :split you can use the space from other windows. But when the space from the current window is sufficient that is not needed. That is what this patch fixes. Another situation: I often have a window open to a file where I add remarks. This only needs to be a few lines tall. When I split the main window this other window is suddenly made a lot bigger, and I have to resize it again. After this patch it works as I would expect. Although I think Tony is correct in his interpretation of the :help on equalalways, I too have never been happy with the way it worked. I prefer this new not-really-equal-equalalways. Perhaps this patch should support a 'pseudoeuqalalways' option? --Suresh --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: tarball and unpacked top directory name syncronization
Per [...] Per Per Most opensource packages are named like proj- Per version.tar.gz, or bz2 for that matter. After Per uncompress/untar, the top directory is similar to tarball Per without extensions proj-version. Per Per [...] Per Per Unfortunally, when uncompressing and untar'ing vim- Per 7.1.tar.bz2 it leaves me with a topdir named vim71. Per Per [...] Per Per Is it possible to have this reworked so that vim follows same Per scheme as about 99% of the rest of the world does? :) Tony replied indicating why appending the version to the name of the vim directory is useful. Tony: I think you misunderstood Per. Per is for appending the version to the vim directory; he is asking for consistency in the version tag appended to the directory and the name of the tar file. So Per would like vim-7.1.tar.bz2 to create vim-7.1 (instead of vim71) Perhaps Per would also be happy with vim71.tar.bz2. Personally, I think foo.tar.bz2 should create the directory foo. Barm A change like this will break existing build scripts. Barm Barm I don't see how this different name can cause a problem. Barm Works fine for the FreeBSD port, Debian, etc. Not clear if in change like this Barm is referring to changing the directory created to vim-7.1 or changing the name of the tar-ball to vim71.tar.bz2. Per: Can't your script inspect vim-7.1.tar to find out the name of the top directory (perhaps via tar -tf vim-7.1.tar)? --Suresh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups vim_dev group. To post to this group, send email to vim_dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/vim_dev?hl=en -~--~~~~--~~--~--~---