Re: Symbolic links to Vim plugins not working for Cygwin

[Thomas]

Windows shortcuts are different things than cygwin symlinks.


There is an option though to make cygwin symlinks be windows shortcuts 
but these need some attribute (R I think) to be set. I don't know if 
this help in this situation though.


Thomas.

Re: "describe-bindings" in VIM ?

[Yakov Lerner]

On 4/26/06, Meino Christian Cramer <[EMAIL PROTECTED]> wrote:
>  is there an equivalent or similiar to the emacs command "describe-bindings",
>  which dumps a list of all keys, which are bind to function and
>  therefore available via key shortcuts ?

User-defined  maps are printed by :map and :imap commands.
Vim builtin keys are available as one long list in :help index

Yakov

Re: Symbolic links to Vim plugins not working for Cygwin

[Eric Arnold]

This would be handy, but I can't find such an option so far.  Any
clues as to where to look.?

On 4/26/06, Thomas <[EMAIL PROTECTED]> wrote:
> > Windows shortcuts are different things than cygwin symlinks.
>
> There is an option though to make cygwin symlinks be windows shortcuts
> but these need some attribute (R I think) to be set. I don't know if
> this help in this situation though.
>
> Thomas.
>
>

Re: Insert Visual mode

[Eric Arnold]

On 4/26/06, Gerald Lai <[EMAIL PROTECTED]> wrote:
> On Tue, 25 Apr 2006, Benji Fisher wrote:
>
> > On Sat, Apr 22, 2006 at 11:11:33AM -0700, Gerald Lai wrote:
> >>> From Normal mode, typing "i" will elicit
> >>
> >>   -- INSERT --
> >>
> >> Then typing "v" will elicit
> >>
> >>   -- (insert) VISUAL --
> >>
> >> My question is, what keystroke will elicit
> >>
> >>   -- INSERT VISUAL --
> >>
> >> ?
> >
> > AFAIK there is no such mode.  Have you seen it?  Or do you think
> > there should be some such mode?
>
> Yes, I have seen it, and can reproduce it. I never thought I could find
> a simple test case to illustrate it until now:
>
>fun! InsVis()
>  exe "normal! \wv"

BTW, I don't have to switch windows to get these modes to work.  Simply
   normal! V

is enough.


>  return ""
>   [...]
> The -- INSERT VISUAL -- mode is quite a wacky mode. I think it's a
> corner case that could possibly happen.. something that only developers
> would be aware of.


I wonder if any of this is supported, even ^Ov  .  I'm not sure what
I'd use them for.

Re: Symbolic links to Vim plugins not working for Cygwin

[Eric Arnold]

Note:  the Win32 Gvim70f  doesn't handle Windows shortcuts.  It opens
the file, but the file is damaged.  I don't know if it is supposed to.


On 4/26/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> This would be handy, but I can't find such an option so far.  Any
> clues as to where to look.?
>
> On 4/26/06, Thomas <[EMAIL PROTECTED]> wrote:
> > > Windows shortcuts are different things than cygwin symlinks.
> >
> > There is an option though to make cygwin symlinks be windows shortcuts
> > but these need some attribute (R I think) to be set. I don't know if
> > this help in this situation though.
> >
> > Thomas.
> >
> >
>

Re: Symbolic links to Vim plugins not working for Cygwin

[Thomas]

Eric Arnold wrote:

This would be handy, but I can't find such an option so far.  Any
clues as to where to look.?


On the command line, use the attrib command. Try attrib /? first.

If you use cygwin's ln -s to create the shortcut the flag should be set 
anyway. But you might also want to browse the cygwin faq or manual? to 
find out more on this topic.


http://cygwin.com/faq/faq.using.html#faq.using.shortcuts

Re: failure to create de .spl files via aap

[Christian Ebert]

* Bram Moolenaar on Tuesday, April 25, 2006 at 13:40:25 +0200:
> It's possible that the Myspell files were updated since I made the diff.
> Perhaps you can take over maintenance of the German dictionary?

I feel morally blackmailed now ;-) At the moment I force myself
to say no because there's just too much other stuff going on but
I'm gonna look into the aap stuff and try to understand the tasks
of a maintainer in the README. If it can be done without too much
manual work, I come back to you.

> Perhaps Vim runs out of memory?

A first try by changing mm in the aap recipe didn't work. Once I
found some time I'm gonna try without aap and so on to narrow
down the issue.

Thanks.

c
-- 
_B A U S T E L L E N_ lesen!  --->> 

RE: Could find where the error is coming from

[SHANKAR R-R66203]

Thanks Gerald and  Eric,
I now greped for browsefilter.
I could get hold of it in verilog.vim inside ftplugin dir

I removed the b:browsefilter from the unlet portion, the error is not coming 
now.


Thanks a lot guys
Shankar


>-Original Message-
>From: Gerald Lai [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, April 26, 2006 11:30 AM
>To: SHANKAR R-R66203
>Cc: 'vim@vim.org'
>Subject: Re: Could find where the error is coming from
>
>On Wed, 26 Apr 2006, SHANKAR R-R66203 wrote:
>
>> I am using tags to browse the code.
>> For the first time, when I press CTRL-] to enter a module, everything
>works properly.
>>
>> But when I press the CTRL-] second time onwards, I get this annoying
>Error message.
>> ---
>> Error detected while processing function 8_LoadFTPlugin:
>> line3:
>> E108: No such variable: "b:browsefilter"
>> ---
>> Although the Error message is reported, the vim takes me properly to the
>intended file.
>>
>> Why this message is coming and from which file this is coming ?
>> I tried to grep for "8_LoadFTPlugin", but could not find anywhere.
>> Any help is appreciated.
>
>Hi Shankar,
>
>I think the function you're looking for is in the file
>
>   $VIM/ftplugin.vim
>
>Here's the latest version on CVS:
>
>
>http://cvs.sourceforge.net/viewcvs.py/vim/vim7/runtime/ftplugin.vim?rev=1.4
>&view=markup
>
>I see that line 3 of the function is:
>
>   unlet! b:undo_ftplugin b:did_ftplugin
>
>The error code E108 does have something to do with line 3. After doing
>
>   :help E108
>
>I get (on Vim 6.3)
>
> *:unlet* *:unl* *E108*
>   :unl[et][!] {var-name} ...
> Remove the internal variable {var-name}.  Several
> variable names can be given, they are all removed.
> With [!] no error message is given for non-existing
> variables.
>
>that points to ":help :unlet".
>
>However, I'm not making much sense out of your problem. Perhaps someone
>else has a better idea.
>--
>Gerald

Re: some problem with vim7f Beta

[Bram Moolenaar]

Vincent Linsong wrote:

> > This behavior of  and  is not new, it was the same befor, too,
> > not only in Vim 7. It is not wise to change it and BTW, it is a good
> > behavior for most people.
> >
> > > My main point is: I don't want to select entry in the completion menu
> > > by pressing CTRL-N or CTRL-P, instead, I want to input enough
> > > characters to make correct entry  become the first entry and it is
> > > highlighted, then I can use CTRL-Y(yes, I have mapped  to
> > > CTRL-Y since I am tempted to use ) to confirm the completion.
> >
> > If you don't want your typed characters to be replaced by the first
> > completion, just add a mapping like this:
> >
> > inoremap  
> 
> Instead of the above map, I set completeopt=menu,preview,longest to get 
> it work.
> 
> > and it won't be replaced. If you type, then the list of possible
> > completions gets smaller. You still have to select the correct entry by
> > yourself, but if I understand you correctly, this might be very near to
> > that, which you seem to want.
> 
> Yes, it is very near to what I want except one thing. But I don't get 
> the point why disable to highlight the top entry in the menu in vim7f 
> (it is not in vim7d)?  And I am sure there are many persons who want to 
> make the top entry highlighted by default. I am not very sure why this 
> is changed in vim7f? 
> Now, is there a easy way to make the top entry highlighted automatically? 

The problem with highlighting the first entry is that you can't use
CTRL-N to use it.  You would get the second entry.  And using CTRL-N to
select an entry is the main method for completion.  Not many people know
about CTRL-Y.

-- 
DENNIS:  Listen -- strange women lying in ponds distributing swords is no
 basis for a system of government.  Supreme executive power derives
 from a mandate from the masses, not from some farcical aquatic
 ceremony.
  The Quest for the Holy Grail (Monty Python)

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: some problem with vim7f Beta

[Bram Moolenaar]

Vincent Linsong wrote:

> >>>This is by design.  Some people mentioned that when using the longest
> >>>common string the first entry should not be selected.  Now you can use
> >>>CTRL-N to select the first entry.  Previously you would need to do
> >>>CTRL-N CTRL-P to get the first entry.
> >>>
> >>   I use the omnicompletion like this:
> >>   I set completeopt=menu,preview,longest . Now consider I input some 
> >>characters of a function's name, for example, the function's name is 
> >>'helloWorld' and I input 'hel'. I am not glad to remember the exact 
> >>function name, so I invoke omnicompletion by , then I know 
> >>what is the exact name of the function, instead of press  or  
> >>multiple times to select it from the menu, I choose to input more 
> >>characters and when function's name becomes the top entry on the menu, I 
> >>will press  to accept it. I think this way is very convenient and I 
> >>know many intelligence like tools works in this way.
> >>   If others have enough reason to change the behavior, would you like 
> >>to add a new option to make two ways work ?  Thanks a lot!
> >
> >I think the current behavior is best for most people.  For you, instead
> >of pressing CTRL-Y you can use CTRL-N and continue typing, that normally
> >stops completion.
>
> If I press CTRL-N, then what I inputed will be replaced with the first 
> entry of the completion menu, but that is not what I want.

I don't get it.  You type characters until the function you were looking
for is the first match.  Then CTRL-N will select that match and you're
done.

There is a conflict between saying that the top entry of the menu is the
one you want and CTRL-N not getting what you want.

-- 
A poem:read aloud:

<> !*''#   Waka waka bang splat tick tick hash,
^"`$$- Caret quote back-tick dollar dollar dash,
[EMAIL PROTECTED] Bang splat equal at dollar under-score,
%*<> ~#4   Percent splat waka waka tilde number four,
&[]../ Ampersand bracket bracket dot dot slash,
|{,,SYSTEM HALTED  Vertical-bar curly-bracket comma comma CRASH.

Fred Bremmer and Steve Kroese (Calvin College & Seminary of Grand Rapids, MI.)

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

How can I detect the OS?

[Eddy Petrişor]

Hello,

Is there a way to detect the OS on which Vim is running?

--
Regards,
EddyP
=
"Imagination is more important than knowledge" A.Einstein

Re: Highlight matched string under cursor

[Benji Fisher]

On Tue, Apr 25, 2006 at 10:38:08PM -0700, Gerald Lai wrote:
> On Tue, 25 Apr 2006, Salman Khilji wrote:
> 
> [snip]
> >What I am looking for is that when I hit the 'n' key,
> >VIM should move the cursor to the next match AND
> >highlight it as well using, for example, the 'Search',
> >or 'IncSearch', or the 'Todo' highlight group.  As
> >soon as I hit the 'n' key again, the previous
> >highlight should disappear and the next one should get
> >highlighted.
> [snip]
> 
> 
> With these assumptions
> 
>   set nohlsearch nocompatible
> 
> you can try these mappings:
> 
>   cmap  /
>   cmap  ?
> 
> Hit Ctrl-n/p to move on to the next/previous search, while you have
> incsearch highlight on.

 Either I am confused or you are.  Why use :cmap for this?

 I would suggest

:nmap n n:match Search /\%#//
:nmap N N:match Search /\%#//

Note that vim is smart enough to avoid recursion here:  you can use
:nnoremap if you want, but :nmap is good enough.

 If this solution works well for you, please consider posting it as
a vim tip:

http://www.vim.org/tips/add_tip.php

HTH --Benji Fisher

Re: Could find where the error is coming from

[Benji Fisher]

On Wed, Apr 26, 2006 at 11:09:38AM +0530, SHANKAR R-R66203 wrote:
> ---
> Error detected while processing function 8_LoadFTPlugin:
> line3:
> E108: No such variable: "b:browsefilter"
> ---
> Although the Error message is reported, the vim takes me properly to the 
> intended file.
> 
> Why this message is coming and from which file this is coming ?
> I tried to grep for "8_LoadFTPlugin", but could not find anywhere.
> Any help is appreciated.

 I see you have already solved the problem, but for future
reference:  the function 8_LoadFTPlugin is defined as
s:LoadFTPlugin() or LoadFTPlugin() in the file listed as #8 when
you use the

:scriptnames

command.

HTH --Benji Fisher

Re: How can I detect the OS?

[James Vega]

On Wed, Apr 26, 2006 at 02:34:02PM +0300, Eddy Petrişor wrote:
> Hello,
> 
> Is there a way to detect the OS on which Vim is running?

You can use has() and the list of features under ":help feature-list" to
determine what type of Vim (and therefore under which OS is running).

  if has('win32')
 ... win32 specific stuff ...
  endif

Search for "version of Vim" from the feature-list help topic and that
should bring you to the different versions for which you can check.

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Insert Visual mode

[Benji Fisher]

On Wed, Apr 26, 2006 at 02:00:07AM -0600, Eric Arnold wrote:
> On 4/26/06, Gerald Lai <[EMAIL PROTECTED]> wrote:
> >
> > Yes, I have seen it, and can reproduce it. I never thought I could find
> > a simple test case to illustrate it until now:
> >
> >fun! InsVis()
> >  exe "normal! \wv"
> 
> BTW, I don't have to switch windows to get these modes to work.  Simply
>normal! V
> 
> is enough.
> 
> >  return ""

 OK, I see it (in vim 7.0f).  I tried

fun! InsVis()
  normal! v
  return ""
endfun

and then from Insert mode,

=InsVis()

This mode seems to be similar to Insert mode, but  takes me to
Visual mode instead of Normal mode.  AFAICT this is undocumented.

HTH --Benji Fisher

Re: Distinguishing Maxima (computer algebra) scripts from assembler files

[François Pinard]

On Sat, Apr 22, 2006 at 01:10:56PM -0600, Robert Dodier wrote:


I have created a syntax colorization file for scripts written for the 
Maxima computer algebra system (http://maxima.sf.net).  [...] PS. 
Here is the syntax file I created: 
http://maxima.sourceforge.net/misc/maxima.vim


Wow, good news, thanks for the reference! :-)

--
François Pinard   http://pinard.progiciels-bpi.ca

Re: line,col regex works with match not syn match..

[Benji Fisher]

On Tue, Apr 25, 2006 at 11:00:37PM -0600, Eric Arnold wrote:
> On 4/25/06, Benji Fisher <[EMAIL PROTECTED]> wrote:
> >
> >  I think the problem is that \%5l is a zero-width pattern.  I do not
> > know whether the docs say this, or if it is supposed to work this way,
> > but perhaps the point is that syntax highlighting applies to
> > characters, and there is no character that matches a zero-width pattern.
> > I tried
> 
> I'm fuzzy on what zero-width means.  I thought that it meant that it
> allows subseqent regexp sequences to match at the positition of the
> zero-width item, not that it couldn't an arbitrary width string.

 I think of it this way:  a zero-width pattern matches in between
two characters.  For example, /\ > syn clear
> > syn match Visual /\%5l./
> 
> Do you mean /\%5l.*/  ?

 I am pretty sure that I tried what I typed.  My pattern should
match each character individually in the fifth line; yours should match
the whole line at once.

> > and that seems to work.  You should be able to tweak this to get a
> > rectangle.
> 
> I've gotten the rectangle I need but it took three steps.  That's
> fine, but I still don't know   syn matchand   match   are
> different.  I suppose it could be related to the zero width thing.  At
> this point, I will simply stop using   match   as a way to prototype
> regexps for   syn match.

 I can do it in one step:

:syn match Search /\%>3l\%<6l\%>2c\%<5c./ containedin=ALL

highlights a little 2x2 square as I edit this e-mail.  (I used
containedin=ALL since I did not do a :syn clear first.)

HTH --Benji Fisher

Re: Ruby + Vim

[Doug Kearns]

On Thu, Apr 20, 2006 at 07:59:31PM +0200, Meino Christian Cramer wrote:


 
> It is the same version I got from their homepage and a even newer
> version of the cvs snapshot is included in the vim-6.4 distro.

No significant changes occurred between the last release of vim-ruby and
the release of Vim 6.4 a week later.

> I think their are not interested in any bug reports anymore...

It might be an idea to try us first don't you think? Just a suggestion. ;-)

Regards,
Doug

Re: vimgrep slow?

[Benji Fisher]

On Sun, Apr 23, 2006 at 10:03:26AM -0600, Eric Arnold wrote:
> Am I doing something wrong, or is  :vimgrep  about 10x slower than a
> shell grep?

 I have not tested, but I assume that there is less overhead in
calling :vimgrep (internal) than the external grep.  I would not be
surprised if the internal function is slower on big jobs, and that this
eventually eats up the advantage of lower overhead.  Still, 10x seems
surprising.  Can you give a test case, perhaps in the vim source
directory?  What is your OS?

HTH --Benji Fisher

Re: How can I detect the OS?

[Frank Terbeck]

Eddy Petri??or <[EMAIL PROTECTED]>:
> Is there a way to detect the OS on which Vim is running?

Hello Eddy,

take a look at
:help feature-list

There are features like amiga, beos, unix and others, which correspond
to the currently running version of vim.

Regards, Frank

Start new line from insert mode

[zzapper]

Hi,

I am in the middle of line in insert mode and want to break out of the line 
and start a new line (above or below)

What I want  is effectively
o   or O

But does Vim7 have a native command for this?


-- 
http://successtheory.com/tips/ Vim, Zsh, MySQL Tips

RE: Making * search for strings

[Halim, Salman]

I use the extreme version:

vnoremap  * "yy:let @/='\(' . substitute( escape( @y,
'$*^[]~\/.' ), '\_s\+', '\\_s\\+', 'g' ) . '\)':set hls

This escapes a lot of stuff, including replacing any whitespace with a
generic expression that includes newlines.  I like it because if you
highlight 'a b' (without the quotes) and hit *, it will subsequently
also match 'a b', 'a\nb' (where the \n indicates that the a
and b are on different lines).  I got the idea from a previous
discussion on this list (might well have been Gerald posting his
mappings earlier).

Oh, and I also wrap the search string in \(\) to allow its use in later
search/replace expressions.  Lastly, I don't perform an actual search,
but rather set the search register and turn on highlights.  Why?  I like
to see all my matches, but I don't really want the cursor to move when I
hit *.

Clobbers the y register, but you can easily change the first two
characters of the mapping to do something else...

In a similar vein, by the way, if you want to search for something
currently on the clipboard, try:

noremap // :let @/[EMAIL PROTECTED]:set hls

Regards,

Salman. 

> -Original Message-
> From: Gerald Lai [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, April 26, 2006 1:30 AM
> To: Suresh Govindachar
> Cc: vim@vim.org
> Subject: Re: Making * search for strings
> 
> On Tue, 25 Apr 2006, Suresh Govindachar wrote:
> 
> >
> > Hello,
> >
> >  By default, * searches for words:  /\  but I 
> > would like it to search for strings:  /stuff_below_cursor  
> One way is 
> > to use the following
> >
> >map * yiw:let @/[EMAIL PROTECTED]
> >
> >  Is there a better way? ("/yiw didn't work.)
> 
> I found this somewhere in Vim tips:
> 
> "visual search
> vnoremap *   
> y/\V=substitute(escape(@@,"/\\"),"\n","n","ge")
> vnoremap  
> y/\V=substitute(escape(@@,"/\\"),"\n","n","ge")
> vnoremap #   
> y?\V=substitute(escape(@@,"?\\"),"\n","n","ge")
> 
> HTH :)
> --
> Gerald
> 

Re: Start new line from insert mode

[Tim Chase]

I am in the middle of line in insert mode and want to break out of the line 
and start a new line (above or below)


What I want  is effectively
o   or O

But does Vim7 have a native command for this?


I cant imagine such a command being added in Vim7 in some 
sort of "native" fashion, given that it's fairly trivial to 
map it:


imap  O
imap  o

or whatever your favorite key happen to be.

I have a similar set of mappings for the opposite 
condition...to insert a line above or below the current one 
without going into insert mode (it just boringly does an "o" 
or "O" and followed by an ).  Not very exciting stuff, 
which makes it likely it won't show up as a native sort of 
command, when there's a pre-existing means to do it with 
minimal fuss.


-tim

Re: Input using meta key under different encoding

[Dave Roberts]

Yakov Lerner wrote:

On 4/25/06, Dave Roberts <[EMAIL PROTECTED]> wrote:
  

I find that if I'm in "latin1" and (in insert mode) type ctrl-v alt-n to
insert the character then get get out of insert mode and put the cursor
on the character and use "ga" to see what it is I get  but if I do
the same thing when the encoding is "cp437" I get .



For me, the sequence i ctrl-v alt-nga results
in exactly same thing:
<î>  <|n>238,  Hex ee,  Octal 356
This is vim7.0f
I used command :set encoding=8bit-cp437 to change encoding.

Some useful info is missinf in your email.

1. Do you toggle some other settings besides 'encoding' when
you switch between the two encodings ? What is exact sequence of
commands that you use to switch encodings ?

2. What is your vim version, and OS ? Console vim or gui vim ?

Yakov

  


WinXP, GVIM 7.0f.

Perform the following steps:

1. GVIM -u NONE -U NONE
2.:set nocompatible
3. Cut and past the following to the command line (all one line)

nmap   :if exists("g:save_encoding") \| exe "set 
encoding=" . g:save_encoding \| unlet g:save_encoding \| else \| let 
g:save_encoding=&encoding \| set encoding=8bit-cp437 \| endif:echo 
&encoding


4. Enter the following key sequence from normal mode (I'm using "Alt-" 
instead of "M-" in the keystrokes) (obviously everything between '<' and 
'>' is a key or key-combination - not a literal less than or greater than):


ii

5. Use k to go up to the first line and ga shows the character is 

6. Use j to go to the second line and ga shows the character is 

That's what I get anyway...

Note: My default is latin1 (not using $LANG). When I press S-F5 the 
command line toggles between "cp437" and "latin1".


Thanks,

- Dave

Re: C++ omnicomplete modification.

[Neil Bird]

Around about 25/04/06 17:11, Bram Moolenaar typed ...

Perhaps someone wants to make a cpp completion script?  I rather not add
all kinds of C++ stuff to the C completion, it will get messy.


  How many more additions would be needed?  Any ideas, anyone?

--
[EMAIL PROTECTED] ~]# rm -f .signature
[EMAIL PROTECTED] ~]# ls -l .signature
ls: .signature: No such file or directory
[EMAIL PROTECTED] ~]# exit

Re: C++ omnicomplete modification.

[hermitte]

Neil Bird <[EMAIL PROTECTED]> wrote:

> Around about 25/04/06 17:11, Bram Moolenaar typed ...
> > Perhaps someone wants to make a cpp completion script?  I rather not add
> > all kinds of C++ stuff to the C completion, it will get messy.
>
>How many more additions would be needed?  Any ideas, anyone?

Don't forget enums.

Consider using something that really understands C++ -- templates can be very
tricky when it comes to completion.

--
Luc Hermitte

Re: Insert Visual mode

[Bram Moolenaar]

Benji Fisher wrote:

> On Wed, Apr 26, 2006 at 02:00:07AM -0600, Eric Arnold wrote:
> > On 4/26/06, Gerald Lai <[EMAIL PROTECTED]> wrote:
> > >
> > > Yes, I have seen it, and can reproduce it. I never thought I could find
> > > a simple test case to illustrate it until now:
> > >
> > >fun! InsVis()
> > >  exe "normal! \wv"
> > 
> > BTW, I don't have to switch windows to get these modes to work.  Simply
> >normal! V
> > 
> > is enough.
> > 
> > >  return ""
> 
>  OK, I see it (in vim 7.0f).  I tried
> 
> fun! InsVis()
>   normal! v
>   return ""
> endfun
> 
> and then from Insert mode,
> 
> =InsVis()
> 
> This mode seems to be similar to Insert mode, but  takes me to
> Visual mode instead of Normal mode.  AFAICT this is undocumented.

This is a really weird mode, being both in Insert mode and having a
Visual selection.  I think I better prevent this from happening.

-- 
BLACK KNIGHT:  I move for no man.
ARTHUR:So be it!
[hah] [parry thrust]
[ARTHUR chops the BLACK KNIGHT's left arm off]
ARTHUR:Now stand aside, worthy adversary.
BLACK KNIGHT:  'Tis but a scratch.
  The Quest for the Holy Grail (Monty Python)

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Vim70f crash - omnicompletion

[David Fishburn]

I am using vim70f on WinXP SP2.

function! sqlcomplete#DrillIntoTable()
if pumvisible()
 exec "normal! i\"
 " call sqlcomplete#Map('column')
 call feedkeys("\\")
endif
 return ""
Endfunction

imap=sqlcomplete#DrillIntoTable()

When the omni popup is visible, to get the current selected item you must
press  while in insert mode (and the list visible).  I am trying to
issue a  from within my function.  All attempts so far have failed.  My
latest attempt is this line:
 exec "normal! i\"

As soon as the above line executes Vim crashes.

So Bram, this is 2 things:
1.  A bug report.
2.  A question, how can I issue a  from within a function executing
during an imap?

TIA,
Dave

Re: "describe-bindings" in VIM ?

[Meino Christian Cramer]

 No, I didn't mean "map" or "command". 

 Think of an vim started without .vimrc loaded.

 I am looking for a command, function or whatever, which
 lists something like this (I dont look for a text file, 
 which lists those keys and functions) :

 Key   Function called
 
 e edit-file() 
 x delete-char()
 dddelete-line()
 . .
 . .
 . .
 . .
 . .



 (...naturally I dont know, whether those functions like "edit-file()" 
 really exists...it is only an example...)


 Keep hacking!
 mcc
 

Re: "describe-bindings" in VIM ?

[Charles E Campbell Jr]

Meino Christian Cramer wrote:

No, I didn't mean "map" or "command". 


Think of an vim started without .vimrc loaded.

I am looking for a command, function or whatever, which
lists something like this (I dont look for a text file, 
which lists those keys and functions) :


Key   Function called

e edit-file() 
x   delete-char()

dddelete-line()
. .
. .
. .
. .
. .
 

Then your answer is: no.  Vim is not an editor implemented mostly atop 
an interpreted  language like emacs is wrapped around lisp.


Regards,
Chip Campbell

Re: C++ omnicomplete modification.

[Aaron Griffin]

On 4/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Consider using something that really understands C++ -- templates can be very
> tricky when it comes to completion.

It's my opinion that ctags is not sufficient for C++ completion
without significant overhead processing to match template types,
namespaces, static members vs instance members, etc etc

Personally I use icomplete, but that uses ctags internally.  I'd be
happy to see a non-ctags solution that is C++ specific.

Re: Vim70f crash - omnicompletion

[Benji Fisher]

On Wed, Apr 26, 2006 at 11:18:35AM -0400, David Fishburn wrote:
> 
> I am using vim70f on WinXP SP2.
> 
> function! sqlcomplete#DrillIntoTable()
> if pumvisible()
>  exec "normal! i\"
>  " call sqlcomplete#Map('column')
>  call feedkeys("\\")
> endif
>  return ""
> Endfunction
> 
> imap=sqlcomplete#DrillIntoTable()
> 
> When the omni popup is visible, to get the current selected item you must
> press  while in insert mode (and the list visible).  I am trying to
> issue a  from within my function.  All attempts so far have failed.  My
> latest attempt is this line:
>  exec "normal! i\"
> 
> As soon as the above line executes Vim crashes.
> 
> So Bram, this is 2 things:
> 1.  A bug report.
> 2.  A question, how can I issue a  from within a function executing
> during an imap?

1. I can confirm the crash, slightly simplified:

fun! DIT()
  if pumvisible()
execute "normal! i\"
  endif
  return ""
endfun

imap  =DIT()

With the completion menu open, I type  and gvim
crashes.  I get the same thing typing =DIT() instead of using
the mapping.

2. I think that what you want is something more along these lines:

fun! DIT2()
  if pumvisible()
return "\"
  else
return ""
  endif
endfun

imap  =DIT2()

HTH --Benji Fisher

Re: Insert Visual mode

[Benji Fisher]

On Wed, Apr 26, 2006 at 05:17:01PM +0200, Bram Moolenaar wrote:
> 
> Benji Fisher wrote:
> 
> > This mode seems to be similar to Insert mode, but  takes me to
> > Visual mode instead of Normal mode.  AFAICT this is undocumented.
> 
> This is a really weird mode, being both in Insert mode and having a
> Visual selection.

 I agree.

> I think I better prevent this from happening.

 No complaints here.  Gerald, I hope you will not miss it! ;)

--Benji Fisher

RE: C++ omnicomplete modification.

[Jeremy P. Owens-Boggs]

Actually it seems that Ctags is sufficient, it seems the problem comes
is correctly identifying what we should be looking for, once we know
that, a Ctags lookup should do the trick. 

-Original Message-
From: Aaron Griffin [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 26, 2006 10:24 AM
To: [EMAIL PROTECTED]
Cc: Neil Bird; Vim Mailing List
Subject: Re: C++ omnicomplete modification.

On 4/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Consider using something that really understands C++ -- templates can 
> be very tricky when it comes to completion.

It's my opinion that ctags is not sufficient for C++ completion without
significant overhead processing to match template types, namespaces,
static members vs instance members, etc etc

Personally I use icomplete, but that uses ctags internally.  I'd be
happy to see a non-ctags solution that is C++ specific.

Re: Start new line from insert mode

[Daniel Einspanjer]

"zzapper" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hi,

I am in the middle of line in insert mode and want to break out of the 
line

and start a new line (above or below)

What I want  is effectively
o   or O

But does Vim7 have a native command for this?


Try o.

:help i_CTRL-O 

Re: Start new line from insert mode

[Daniel Einspanjer]

"Tim Chase" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I have a similar set of mappings for the opposite condition...to insert a 
line above or below the current one without going into insert mode (it 
just boringly does an "o" or "O" and followed by an ).  Not very 
exciting stuff, which makes it likely it won't show up as a native sort of 
command, when there's a pre-existing means to do it with minimal fuss.


Tim, there is also the :norm command..
:norm of

Would do what you want (but I imagine you'd want to map it to save 
keystrokes and that mapping would probably be completely equivalent to your 
current o.


:help :norm 

Re: Start new line from insert mode

[Daniel Einspanjer]

"Daniel Einspanjer" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Tim, there is also the :norm command..
:norm of

Err.. that should be
:norm o

My spell checker thought it knew better than me. :) 

RE: Vim70f crash - omnicompletion

[David Fishburn]

 

> -Original Message-
> From: Benji Fisher [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, April 26, 2006 12:48 PM
> To: vim@vim.org
> Subject: Re: Vim70f crash - omnicompletion
> 
> On Wed, Apr 26, 2006 at 11:18:35AM -0400, David Fishburn wrote:
> > 
> > I am using vim70f on WinXP SP2.
> > 
> > function! sqlcomplete#DrillIntoTable()
> > if pumvisible()
> >  exec "normal! i\"
> >  " call sqlcomplete#Map('column')
> >  call feedkeys("\\")
> > endif
> >  return ""
> > Endfunction
> > 
> > imap=sqlcomplete#DrillIntoTable()
> > 
> > When the omni popup is visible, to get the current selected 
> item you 
> > must press  while in insert mode (and the list visible).  I am 
> > trying to issue a  from within my function.  All 
> attempts so far 
> > have failed.  My latest attempt is this line:
> >  exec "normal! i\"
> > 
> > As soon as the above line executes Vim crashes.
> > 
> > So Bram, this is 2 things:
> > 1.  A bug report.
> > 2.  A question, how can I issue a  from within a function 
> > executing during an imap?
> 
> 1. I can confirm the crash, slightly simplified:
> 
> fun! DIT()
>   if pumvisible()
> execute "normal! i\"
>   endif
>   return ""
> endfun
> 
> imap  =DIT()
> 
> With the completion menu open, I type  and 
> gvim crashes.  I get the same thing typing =DIT() 
> instead of using the mapping.
> 
> 2. I think that what you want is something more along these lines:
> 
> fun! DIT2()
>   if pumvisible()
> return "\"
>   else
> return ""
>   endif
> endfun
> 
> imap  =DIT2()

That will not work for me.
> >  exec "normal! i\"

Since the user can navigate through the entries in the list before pressing
, I need to get the currently selected item before I redisplay the
popup with different values (based on what was highlighted).

> >  " call sqlcomplete#Map('column')
> >  call feedkeys("\\")

So after a issue a  on behalf of the user, I setup the SQL completion
plugin for the next step and trigger omni again using the new feedkeys()
function.  According to the docs feedkeys() will executes the keys once the
function completes.

So as I was typing this up I just realized I can code this as follows:
function! sqlcomplete#DrillIntoTable()
if pumvisible()
call sqlcomplete#Map('column')
call feedkeys("\\\")
else
exec "normal! \"
endif
return ""
Endfunction

Since I technically do not need to hit the  prior to calling into
sqlcomplete#Map.  So the code works as is, and avoids the crash.

But for future developers, I could see a need to be able to retrieve the
currently selected item in the popup, so the question stands although it is
moved way down my priority list.

Thanks for the response Benji, and leading me in the right direction.

Dave

Runtime error in explorer.exe when right clicking with vim70f gvimext.dll installed

[Daniel Einspanjer]

I pulled down latest sources from svn.sf.net.
Compiled under MSVS8 with the following featureset:
   set RUBY_PARAMS=
   RUBY=C:\bin\ruby
   DYNAMIC_RUBY=yes
   RUBY_VER=18
   RUBY_VER_LONG=1.8

   set COMMON_PARAMS=
   FEATURES=HUGE
   CSCOPE=yes
   %RUBY_PARAMS%
   DEFINES=-D_CRT_SECURE_NO_DEPRECATE

   nmake -f Make_mvc.mak %COMMON_PARAMS%
   nmake -f Make_mvc.mak all GUI=yes OLE=yes %COMMON_PARAMS%

Installed the build exes and dlls to c:\bin\vim\vim70f and ran install.exe.
When I right click on a file in explorer I get an MSVC Runtime error dialog:
   Microsoft Visual C++ Runtime Library
   Runtime Error!
   Program: C:\WINDOWS\explorer.exe
   R6034
   An application has made an attempt to load the C runtime library 
incorrectly.

   Please contact the application's support team for more information

If I unregister gvimext.dll then the error goes away.  If I install the 
gvimext.dll from vim64 or my prior vim70e, then the Edit with Vim 
functionality works fine.


Has anyone run into this before? Any ideas?
--
Daniel Einspanjer 

Feedkeys() function is not highlighted

[David Fishburn]

Simple bug report.  When editing a .vim file and using the new feedkeys()
function with vim70f, the syntax highlighter flags it as an error.  Looks
like it hasn't been added to the list of known functions yet.

call feedkeys("\\")

Dave

Re: vimgrep slow?

[Eric Arnold]

I'm using win32 gvim70f.  If I use the externan Cygwin grep

grep -i -r vimgrep .

it returns the results in under a second.

:vimgrep vimgrep **

takes about 20 seconds.

On 4/26/06, Benji Fisher <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 23, 2006 at 10:03:26AM -0600, Eric Arnold wrote:
> > Am I doing something wrong, or is  :vimgrep  about 10x slower than a
> > shell grep?
>
>  I have not tested, but I assume that there is less overhead in
> calling :vimgrep (internal) than the external grep.  I would not be
> surprised if the internal function is slower on big jobs, and that this
> eventually eats up the advantage of lower overhead.  Still, 10x seems
> surprising.  Can you give a test case, perhaps in the vim source
> directory?  What is your OS?
>
> HTH --Benji Fisher
>

Re: Vim70f crash - omnicompletion

[Bram Moolenaar]

David Fishburn wrote:

> I am using vim70f on WinXP SP2.
> 
> function! sqlcomplete#DrillIntoTable()
> if pumvisible()
>  exec "normal! i\"
>  " call sqlcomplete#Map('column')
>  call feedkeys("\\")
> endif
>  return ""
> Endfunction
> 
> imap=sqlcomplete#DrillIntoTable()
> 
> When the omni popup is visible, to get the current selected item you must
> press  while in insert mode (and the list visible).  I am trying to
> issue a  from within my function.  All attempts so far have
> failed.  My latest attempt is this line:
>  exec "normal! i\"
> 
> As soon as the above line executes Vim crashes.

I can reproduce it.  The :normal command invokes Insert mode
recursively, which clears the completion information that still is being
used.  I'll forbid recursive Insert mode when completion is active.

> So Bram, this is 2 things:
> 1.  A bug report.
> 2.  A question, how can I issue a  from within a function executing
> during an imap?

An expression mapping should work.

-- 
MARTHA'S WAY: Don't throw out all that leftover wine. Freeze into ice cubes
  for future use in casseroles and sauces.
MY WAY:   What leftover wine?

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: line,col regex works with match not syn match..

[Eric Arnold]

On 4/26/06, Benji Fisher <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 25, 2006 at 11:00:37PM -0600, Eric Arnold wrote:
> > On 4/25/06, Benji Fisher <[EMAIL PROTECTED]> wrote:
> > >
> > >  I think the problem is that \%5l is a zero-width pattern.  I do not
> > > know whether the docs say this, or if it is supposed to work this way,
> > > but perhaps the point is that syntax highlighting applies to
> > > characters, and there is no character that matches a zero-width pattern.
> > > I tried
> >
> > I'm fuzzy on what zero-width means.  I thought that it meant that it
> > allows subseqent regexp sequences to match at the positition of the
> > zero-width item, not that it couldn't an arbitrary width string.
>
>  I think of it this way:  a zero-width pattern matches in between
> two characters.  For example, /\ in "foo bar".
>
> > > syn clear
> > > syn match Visual /\%5l./
> >
> > Do you mean /\%5l.*/  ?
>
>  I am pretty sure that I tried what I typed.  My pattern should
> match each character individually in the fifth line; yours should match
> the whole line at once.
>
> > > and that seems to work.  You should be able to tweak this to get a
> > > rectangle.
> >
> > I've gotten the rectangle I need but it took three steps.  That's
> > fine, but I still don't know   syn matchand   match   are
> > different.  I suppose it could be related to the zero width thing.  At
> > this point, I will simply stop using   match   as a way to prototype
> > regexps for   syn match.
>
>  I can do it in one step:
>
> :syn match Search /\%>3l\%<6l\%>2c\%<5c./ containedin=ALL
>
> highlights a little 2x2 square as I edit this e-mail.  (I used
> containedin=ALL since I did not do a :syn clear first.)

Cool.  Thanks.  Any idea why it works differently than   :match  .

Bug in i_^X

[Hari Krishna Dara]

In Vim 6.3, hitting ^X in insert mode when the cursor is on the number:

08)

produced:

03778)

This is a bug which seems to be fixed in Vim 7.0f, but it doesn't work
right, as it now produces:

7)

instead of:

07)

If the string is say,

07)

both versions correctly produce,

06)

-- 
Thanks,
Hari

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: vimgrep slow?

[Yakov Lerner]

On 4/26/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> I'm using win32 gvim70f.  If I use the externan Cygwin grep
>
> grep -i -r vimgrep .
>
> it returns the results in under a second.
>
> :vimgrep vimgrep **
>
> takes about 20 seconds.

1. I did

:20verb vimgrep lakslaskjda $VIMRUNTIME/**

and found, to my surprise,  that vim sources .viminfo and
executes 'au BufRead'  for *every* searched file.
This cannot but slow down.It's hundeds lines of unnecessary scripts
per every searched file.

   2. I tried to see what's the overhead of this unnecessary
'au BufRead' and tried ':set eventignore=all'. To my 2nd surprise,
vimgrep ignored ':set eventignore=all' and continued to
load BufRead autocommands and .viminfo for each file.

Yakov

Re: Bug in i_^X

[Gerald Lai]

On Wed, 26 Apr 2006, Hari Krishna Dara wrote:



In Vim 6.3, hitting ^X in insert mode when the cursor is on the number:

08)

produced:

03778)

This is a bug which seems to be fixed in Vim 7.0f, but it doesn't work
right, as it now produces:

7)

instead of:

07)

If the string is say,

07)

both versions correctly produce,

06)


Confirmed for Vim 6.3. Seems like some kind of octal increment/decrement
confusion.

However, I think Hari meant to say Normal mode instead of Insert mode.

Vim thinks that it's an octal number because of 0 followed by [0-9]\+
(yes, it should be [0-7]\+). But when it encounters [8-9]\+\d*$, it
takes 0 as the octal number itself, and not as the octal indicator (as
"0x" is the hex indicator).

This is evident with:

  08123

Placing the cursor on any of the 5 digits and hitting Ctrl-x produces:

  03778123

Some may say it is correct operation ;) except for the fact that Vim
confuses the indicator for the number itself. Hence, performing the same
on:

  008123

also produces:

  03778123

In this case, the good 0 is decremented to -1 in octal.

Of course, the fix for this behavior on any Vim is

  :set nrformats-=octal

See ":help 'nrformats'".

HTH :)
--
Gerald

Re: Insert Visual mode

[Gerald Lai]

On Wed, 26 Apr 2006, Benji Fisher wrote:


On Wed, Apr 26, 2006 at 05:17:01PM +0200, Bram Moolenaar wrote:


Benji Fisher wrote:


This mode seems to be similar to Insert mode, but  takes me to
Visual mode instead of Normal mode.  AFAICT this is undocumented.


This is a really weird mode, being both in Insert mode and having a
Visual selection.


I agree.


I think I better prevent this from happening.


No complaints here.  Gerald, I hope you will not miss it! ;)


Nah. Good riddance :) It will actually fix a bug in one of my scripts.

Bram, could you make Vim do

  -- (insert) VISUAL --

instead when it now does

  -- INSERT VISUAL --

?

--
Gerald

Re: Vim GUI repositioning itself - Windows / extended monitors

[Daniel Einspanjer]

"David Fishburn" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

This seems to be a new behaviour / annoyance of Vim7.
:set columns+=30
At this point, Vim will reposition itself to be in the main screens area, 
so
it will move from 1 monitor to the other.  I then have to drag it back 
again

(or use a mapping).


Happens for me in both Vim7 and Vim64. (XP SP2 extended monitor) 

Re: others like startinsert for Vim7?

[Charles E Campbell Jr]

Eric Arnold wrote:


It occured to me that it would be nice to have

startsearch   (forward/back)
startex(begin :ex mode)
etc.

since there doesn't seem to be (?) any way to start modes other than
insert from Vim scripts.

 


Well, there's startreplace !

Regards,
Chip Campbell

Re: vimgrep slow?

[Charles E Campbell Jr]

Eric Arnold wrote:


I'm using win32 gvim70f.  If I use the externan Cygwin grep

grep -i -r vimgrep .

it returns the results in under a second.

:vimgrep vimgrep **

takes about 20 seconds.
 

Without having looked at the code, let me assume that vimgrep is simply 
re-using its regular expression

pattern matching code.

I believe that grep itself has several pattern matching algorithms 
built-in.  If one is looking for
a straight string, Boyer-Moore is a very good algorithm (it ends up 
looking at approx O(N/M)
usually, where N=qty chars in text, M=qty chars in pattern).  Regular 
expressions will, at best,

usually be about O(N) (worst case is a _lot_ longer).

One can look for multiple words quickly with an Aho-Corasik pattern 
matcher.  Again, they must

be fixed words, no wildcards, etc.

So, unless Bram installed a lot of pattern matching algorithms into ViM 
just to support :vimgrep,
I'm not surprised that grep can be a lot faster.  Try both algorithms 
with a pattern consisting

of a single (non-magic) character and comparing them.

Another point: :vimgrep is often making a list out of the matches, 
thereby incurring memory

management overhead.

Regards,
Chip Campbell

RE: Making * search for strings

[Gerald Lai]

On Wed, 26 Apr 2006, Halim, Salman wrote:


I use the extreme version:

vnoremap  * "yy:let @/='\(' . substitute( escape( @y,
'$*^[]~\/.' ), '\_s\+', '\\_s\\+', 'g' ) . '\)':set hls

This escapes a lot of stuff, including replacing any whitespace with a
generic expression that includes newlines.  I like it because if you
highlight 'a b' (without the quotes) and hit *, it will subsequently
also match 'a b', 'a\nb' (where the \n indicates that the a
and b are on different lines).  I got the idea from a previous
discussion on this list (might well have been Gerald posting his
mappings earlier).


Good idea :) I'll adopt it for my . Question, do you think it
would be useful to extend this to numbers too? For example, visual
matching "123" results in "\d\+"?


Oh, and I also wrap the search string in \(\) to allow its use in later
search/replace expressions.  Lastly, I don't perform an actual search,
but rather set the search register and turn on highlights.  Why?  I like
to see all my matches, but I don't really want the cursor to move when I
hit *.

[snip]

The only reason I use

  let @/=""

in mappings is not to polute the search history. If you don't want the
cursor to move when * is hit, you can do:

  nnoremap * *
  nnoremap # #

HTH :)
--
Gerald

RE: Making * search for strings

[Halim, Salman]

> > I use the extreme version:
> >
> > vnoremap  * "yy:let @/='\(' . substitute( escape( @y, 
> > '$*^[]~\/.' ), '\_s\+', '\\_s\\+', 'g' ) . '\)':set hls
> >
> > This escapes a lot of stuff, including replacing any 
> whitespace with a 
> > generic expression that includes newlines.  I like it 
> because if you 
> > highlight 'a b' (without the quotes) and hit *, it will subsequently
> > also match 'a b', 'a\nb' (where the \n 
> indicates that the a
> > and b are on different lines).  I got the idea from a previous 
> > discussion on this list (might well have been Gerald posting his 
> > mappings earlier).
> 
> Good idea :) I'll adopt it for my . Question, do 
> you think it would be useful to extend this to numbers too? 
> For example, visual matching "123" results in "\d\+"?

I thought about doing substitutions to non-whitespace characters
(numbers with \d\+ and letters/underscores with \w\+) but it seemed to
match too many things.  Admittedly, I will occasionally have something
like this:

Word1 generalStuff Word2

Where 'generalStuff' could be any word (I don't care about it, as long
as it's flanked by Word1 and Word2); when that happens, I do end up
manually modifying the search after the *, but that happens infrequently
enough (whether with numbers or digits) that it doesn't inconvenience me
that much.

How about another mapping that does something like:

:let @/=substitute(@/, '\d\+', '\\d\\+', 'g')

That way, when you decide you really want generic numbers, you can just
hit the mapping after the * to make it happen.

Regards,

Salman.

Re: Feedkeys() function is not highlighted

[Bram Moolenaar]

David Fishburn wrote:

> Simple bug report.  When editing a .vim file and using the new feedkeys()
> function with vim70f, the syntax highlighter flags it as an error.  Looks
> like it hasn't been added to the list of known functions yet.
> 
> call feedkeys("\\")

The Vim highlighting always lags behind a few days.  Charles has sent me
an updated syntax file, feedkeys() is highlighted properly now.

-- 
LAUNCELOT: I am, sir. I am a Knight of King Arthur.
FATHER:'Mm ... very nice castle, Camelot ... very good pig country
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Re: vimgrep slow?

[Bram Moolenaar]

Yakov Lerner wrote:

> On 4/26/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> > I'm using win32 gvim70f.  If I use the externan Cygwin grep
> >
> > grep -i -r vimgrep .
> >
> > it returns the results in under a second.
> >
> > :vimgrep vimgrep **
> >
> > takes about 20 seconds.
> 
> 1. I did
> 
> :20verb vimgrep lakslaskjda $VIMRUNTIME/**
> 
> and found, to my surprise,  that vim sources .viminfo and
> executes 'au BufRead'  for *every* searched file.
> This cannot but slow down.It's hundeds lines of unnecessary scripts
> per every searched file.

This is so that you can grep compressed, encrypted and other files.
You have of course made sure that BufRead autocommands don't slow down
loading a file.

>2. I tried to see what's the overhead of this unnecessary
> 'au BufRead' and tried ':set eventignore=all'. To my 2nd surprise,
> vimgrep ignored ':set eventignore=3Dall' and continued to
> load BufRead autocommands and .viminfo for each file.

That is a bug.  Vimgrep adds something to 'eventignore', causing "all"
no longer to be recognized.  I'll fix that.

-- 
If your life is a hard drive,
Christ can be your backup.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

RE: Making * search for strings

[David Fishburn]

 

> -Original Message-
> From: Suresh Govindachar [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, April 26, 2006 1:00 AM
> To: vim@vim.org
> Subject: Making * search for strings
> 
> 
> Hello,
> 
>   By default, * searches for words:  /\
>   but I would like it to search for strings:  /stuff_below_cursor
>   One way is to use the following
> 
> map * yiw:let @/[EMAIL PROTECTED]
> 
>   Is there a better way? ("/yiw didn't work.)

I have the following in my vimrc:
" Courtesy of Michael Naumann, Jürgen Krämer
" Visually select text, then search for it
if version >= 602
" Here are two enhanced versions of these mappings which use VIM 6.2's
" getregtype() function to determine whether the unnamed register
contains 
" a characterwise, linewise or blockwise selection. After the search has

" been executed, the register *and* its type can then be restored with 
" setreg(). 
vnoremap  * :
  \let old_reg=getreg('"')
  \let old_regmode=getregtype('"')
  \gvy/=substitute(substitute(
  \escape(@", '\\/.*$^~[]' ), "\n$", "", ""),
  \"\n", '\\_[[:return:]]', "g")
  \:call setreg('"', old_reg, old_regmode)
vnoremap  # :
  \let old_reg=getreg('"')
  \let old_regmode=getregtype('"')
  \gvy?=substitute(substitute(
  \escape(@", '\\/.*$^~[]' ), "\n$", "", ""),
  \"\n", '\\_[[:return:]]', "g")
  \:call setreg('"', old_reg, old_regmode)
endif

Basically, using visual mode, select whatever text you like and press * (or
# for reverse).  These use the same keys as *,# in normal mode, so they are
very easy to remember.  I use these maps all the time, very useful.

HTH,
Dave

Re: others like startinsert for Vim7?

[Eric Arnold]

Actually, "feedkeys()" might be the answer, although I'm still having
trouble with the bad interaction with getchar() (it causes subsequent
getchar() calls to return as if there is an infinite input of the
feedchar()).





On 4/22/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> It occured to me that it would be nice to have
>
> startsearch   (forward/back)
> startex(begin :ex mode)
> etc.
>
> since there doesn't seem to be (?) any way to start modes other than
> insert from Vim scripts.
>

RE: Making * search for strings

[Gerald Lai]

On Wed, 26 Apr 2006, Halim, Salman wrote:


I use the extreme version:

vnoremap  * "yy:let @/='\(' . substitute( escape( @y,
'$*^[]~\/.' ), '\_s\+', '\\_s\\+', 'g' ) . '\)':set hls

This escapes a lot of stuff, including replacing any whitespace with a
generic expression that includes newlines.  I like it because if you
highlight 'a b' (without the quotes) and hit *, it will subsequently
also match 'a b', 'a\nb' (where the \n indicates that the a
and b are on different lines).  I got the idea from a previous
discussion on this list (might well have been Gerald posting his
mappings earlier).


Good idea :) I'll adopt it for my . Question, do
you think it would be useful to extend this to numbers too?
For example, visual matching "123" results in "\d\+"?


I thought about doing substitutions to non-whitespace characters
(numbers with \d\+ and letters/underscores with \w\+) but it seemed to
match too many things.  Admittedly, I will occasionally have something
like this:

[snip]

How about another mapping that does something like:

:let @/=substitute(@/, '\d\+', '\\d\\+', 'g')

[snip]

Thanks. I think I'll include number generalization in my "extreme"
version of  ;) Seems useful enough. It now looks like:

  (one line)
  vnoremap  
y/\V=substitute(substitute(escape(@@,'/\'),'\_s\+','\\_s\\+','ge'),'\d\+','\\d\\+','ge')

--
Gerald

Re: vimgrep slow?

[Mikolaj Machowski]

Dnia niedziela, 23 kwietnia 2006 18:03, Eric Arnold napisał:
> Am I doing something wrong, or is  :vimgrep  about 10x slower than a
> shell grep?

It is faster when looking in current file and slower when scanning
multiple files. Reason for that is probably fact Vim is traditionally
slow with I/O operations.

But usually whole process is faster with vimgrep because
I don't have to check man grep for obscure details of regexp syntax ;)

m.

Re: Insert Visual mode

[Bram Moolenaar]

Gerald Lai wrote:

> On Wed, 26 Apr 2006, Benji Fisher wrote:
> 
> > On Wed, Apr 26, 2006 at 05:17:01PM +0200, Bram Moolenaar wrote:
> >>
> >> Benji Fisher wrote:
> >>
> >>> This mode seems to be similar to Insert mode, but  takes me to
> >>> Visual mode instead of Normal mode.  AFAICT this is undocumented.
> >>
> >> This is a really weird mode, being both in Insert mode and having a
> >> Visual selection.
> >
> > I agree.
> >
> >> I think I better prevent this from happening.
> >
> > No complaints here.  Gerald, I hope you will not miss it! ;)
> 
> Nah. Good riddance :) It will actually fix a bug in one of my scripts.
> 
> Bram, could you make Vim do
> 
>-- (insert) VISUAL --
> 
> instead when it now does
> 
>-- INSERT VISUAL --

With the weird mode prevented, this should never appear now.  Perhaps I
should offer a reward if you are still able to get it somehow!

-- 
There are 10 kinds of people: Those who understand binary and those who don't.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

Vimdiff

[vim]

When I'm opening a file and then going into File->Split diff with and 
choose another file, I get the following error:


E97: Cannot create diffs

Version used:
Version gVim 7.0f beta
MS-Windows 32 bit GUI version

Regards,
Laurent

Bugs in feedkeys(): doesn't work with silent and vim went into a loop

[Hari Krishna Dara]

I am trying to use feedkeys() to give input to a Vim command that is
expecting input from the user, and it works if the command is not
executed using :silent prefix. Here is an example (executed on JDK 1.4.2
source):

:ta Integer
tag 1 of 11 or more
:call feedkeys("4\") | ts


If I prefix the :ts command with :silent, this doesn't work, and the fed
keys are handled by Vim as normal mode commands.

:call feedkeys("4\") | silent ts

I was doing this (feeding keys) in Vim 6.3 using a dynamic mapping,
which suffered from the same problem, so had to use the command without
silent, and that is a big usability issue, so was really hoping that
feedkeys() will solve this problem, but unfortuately it doesn't.

Also, I just observed that while experimenting with feedkeys(), Vim went
into a loop. It responds to ^C with a beep, but ignores all my other
keys. It essentially stopped responding to user input (keyboard and
mouse), but quit gracefully when I hit the window close button. Here is
how to reproduce it (again using JDK 1.4.2 source, but should work on
any tags):

:ta Integer
:ta Integer
:call feedkeys("4\") | silent ts
^T
:call feedkeys("4\") | silent ts
E426: tag not found: Integer


The "^T" is to return back to the previous tag in the stack.

-- 
Thanks,
Hari

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Insert Visual mode

[Gerald Lai]

On Thu, 27 Apr 2006, Bram Moolenaar wrote:



Gerald Lai wrote:


On Wed, 26 Apr 2006, Benji Fisher wrote:


On Wed, Apr 26, 2006 at 05:17:01PM +0200, Bram Moolenaar wrote:


Benji Fisher wrote:


This mode seems to be similar to Insert mode, but  takes me to
Visual mode instead of Normal mode.  AFAICT this is undocumented.


This is a really weird mode, being both in Insert mode and having a
Visual selection.


I agree.


I think I better prevent this from happening.


No complaints here.  Gerald, I hope you will not miss it! ;)


Nah. Good riddance :) It will actually fix a bug in one of my scripts.

Bram, could you make Vim do

   -- (insert) VISUAL --

instead when it now does

   -- INSERT VISUAL --


With the weird mode prevented, this should never appear now.  Perhaps I
should offer a reward if you are still able to get it somehow!


So what happens when

  i=Test()

is done for

  fun! Test()
normal! v
return ""
  endf

?

Does it go into -- (insert) VISUAL -- mode? It should.

--
Gerald

Re: Bug in i_^X

[Hari Krishna Dara]

On Wed, 26 Apr 2006 at 12:04pm, Gerald Lai wrote:

> On Wed, 26 Apr 2006, Hari Krishna Dara wrote:
>
> >
> > In Vim 6.3, hitting ^X in insert mode when the cursor is on the number:
> >
> > 08)
> >
> > produced:
> >
> > 03778)
> >
> > This is a bug which seems to be fixed in Vim 7.0f, but it doesn't work
> > right, as it now produces:
> >
> > 7)
> >
> > instead of:
> >
> > 07)
> >
> > If the string is say,
> >
> > 07)
> >
> > both versions correctly produce,
> >
> > 06)
>
> Confirmed for Vim 6.3. Seems like some kind of octal increment/decrement
> confusion.
>
> However, I think Hari meant to say Normal mode instead of Insert mode.
>
> Vim thinks that it's an octal number because of 0 followed by [0-9]\+
> (yes, it should be [0-7]\+). But when it encounters [8-9]\+\d*$, it
> takes 0 as the octal number itself, and not as the octal indicator (as
> "0x" is the hex indicator).
>
> This is evident with:
>
>08123
>
> Placing the cursor on any of the 5 digits and hitting Ctrl-x produces:
>
>03778123
>
> Some may say it is correct operation ;) except for the fact that Vim
> confuses the indicator for the number itself. Hence, performing the same
> on:
>
>008123
>
> also produces:
>
>03778123
>
> In this case, the good 0 is decremented to -1 in octal.
>
> Of course, the fix for this behavior on any Vim is
>
>:set nrformats-=octal
>
> See ":help 'nrformats'".
>
> HTH :)
> --
> Gerald
>
>

Yes, I meant normal mode only and thanks for the analysis and
workaround, it gets the job done for me.

-- 
Thanks,
Hari

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: vimgrep slow?

[Hari Krishna Dara]

On Wed, 26 Apr 2006 at 10:01pm, Yakov Lerner wrote:

> On 4/26/06, Eric Arnold <[EMAIL PROTECTED]> wrote:
> > I'm using win32 gvim70f.  If I use the externan Cygwin grep
> >
> > grep -i -r vimgrep .
> >
> > it returns the results in under a second.
> >
> > :vimgrep vimgrep **
> >
> > takes about 20 seconds.
>
> 1. I did
>
> :20verb vimgrep lakslaskjda $VIMRUNTIME/**
>
> and found, to my surprise,  that vim sources .viminfo and
> executes 'au BufRead'  for *every* searched file.
> This cannot but slow down.It's hundeds lines of unnecessary scripts
> per every searched file.
>
>2. I tried to see what's the overhead of this unnecessary
> 'au BufRead' and tried ':set eventignore=all'. To my 2nd surprise,
> vimgrep ignored ':set eventignore=all' and continued to
> load BufRead autocommands and .viminfo for each file.
>
> Yakov

I had a suspicion of this, but when I checked the buffer-list these
files didn't show up, so I presumed that Vim doesn't really load them as
regular buffers to do the search, so I wonder how the BufRead
autocommand gets fired.

-- 
Hari

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: some problem with vim7f Beta

[Linsong]

Bram Moolenaar wrote:


Vincent Linsong wrote:

 


This is by design.  Some people mentioned that when using the longest
common string the first entry should not be selected.  Now you can use
CTRL-N to select the first entry.  Previously you would need to do
CTRL-N CTRL-P to get the first entry.

 


 I use the omnicompletion like this:
 I set completeopt=menu,preview,longest . Now consider I input some 
characters of a function's name, for example, the function's name is 
'helloWorld' and I input 'hel'. I am not glad to remember the exact 
function name, so I invoke omnicompletion by , then I know 
what is the exact name of the function, instead of press  or  
multiple times to select it from the menu, I choose to input more 
characters and when function's name becomes the top entry on the menu, I 
will press  to accept it. I think this way is very convenient and I 
know many intelligence like tools works in this way.
 If others have enough reason to change the behavior, would you like 
to add a new option to make two ways work ?  Thanks a lot!
   


I think the current behavior is best for most people.  For you, instead
of pressing CTRL-Y you can use CTRL-N and continue typing, that normally
stops completion.
 

If I press CTRL-N, then what I inputed will be replaced with the first 
entry of the completion menu, but that is not what I want.
   



I don't get it.  


Sorry, my words is a little confusing.


You type characters until the function you were looking
for is the first match.  Then CTRL-N will select that match and you're
done.
 

In fact, I input more characters until the function I am looking for is 
the the first match, under this case, I want to select the first match 
and make the menu disappear(why? because to my impression, the 
completion is not done until I select some entry and the completion menu 
disappears). But now I have to press CTRL-N CTRL-E to do so, that is not 
very convenient.


Yes, I can make a map make it easier, for example I have the following 
match:

if exists('*pumvisible')
   inoremap  =pumvisible() ? "\C-y>" : 
"\Enter>"

endif
   It works very well under vim7d Beta with 
completeopt=menu,preview,longest, this map just makes Enter as the 
confirm key instead of  since I am tempted to use Enter as the 
confirm key. It works in the following two cases:
   case 1: I input charactes and when the first match is what I want, I 
just press Enter to confirm, what I inputed is completed and the 
completion menu disappear
   case 2: I use CTRL-N or CTRL-P to change the highlighted entry to 
the one I want, then I press Enter to confirm.
   But in vim7f Beta, since the first match has not been highlighted 
any more, the map does not work in case 1. I can modify it a little to 
make it work:

   if exists('*pumvisible')
   inoremap  =pumvisible() ? "\C-n>\C-y>" : 
"\Enter>"

   endif
  But it will not work in case 2. I can not work out a way to make it 
work in case 1 and case 2.
  I know what is the reason of the change between vim7f and vim7d and I 
think it is very reasonable. But I still suggest there should be an 
option to highlight the first match of completion menu.


Thanks.

BR
Vincent
   


There is a conflict between saying that the top entry of the menu is the
one you want and CTRL-N not getting what you want.