Re: How about a release?

['Suresh Govindachar' via vim_dev]

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

['Suresh Govindachar' via vim_dev]

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

['Suresh Govindachar' via vim_dev]

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

['Suresh Govindachar' via vim_dev]

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

['Suresh Govindachar' via vim_dev]

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)

['Suresh Govindachar' via vim_dev]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

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?

[Suresh Govindachar]

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?

[Suresh Govindachar]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

  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?

[Suresh Govindachar]

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

[Suresh Govindachar]

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?

[Suresh Govindachar]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

  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

[Suresh Govindachar]

  
  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)

[Suresh Govindachar]

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

[Suresh Govindachar]

 

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

[Suresh Govindachar]

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

[Suresh Govindachar]

.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

[Suresh Govindachar]

  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

[Suresh Govindachar]

 

  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

[Suresh Govindachar]

 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

[Suresh Govindachar]

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

[Suresh Govindachar]

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

[Suresh Govindachar]

  [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

[Suresh Govindachar]

 
  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?

[Suresh Govindachar]

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

[Suresh Govindachar]

   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

[Suresh Govindachar]

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?

[Suresh Govindachar]

   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

[Suresh Govindachar]

  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

[Suresh Govindachar`]

 
  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

[Suresh Govindachar`]

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