omni-completion

2007-05-09 Thread Normandie Azucena

hi all!
this will seem to be a dumb question.
what is omni-completion?
How can I use it in vim?
How can I create my own?

tnx in advance!



Re: omni-completion

2007-05-09 Thread Gary Johnson
On 2007-05-09, Normandie Azucena [EMAIL PROTECTED] wrote:
 hi all!
 this will seem to be a dumb question.
 what is omni-completion?
 How can I use it in vim?
 How can I create my own?

   :help compl-omni
   :help 24.3

HTH,
Gary

-- 
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
 | Spokane, Washington, USA


Re: omni-completion

2007-05-09 Thread Jean-Rene David
* Normandie Azucena [2007.05.09 09:30]:
 this will seem to be a dumb question.
 what is omni-completion?
 How can I use it in vim?
 How can I create my own?

Have you given 

:h omni-completion

a try?

-- 
JR


Bitchy omni completion with own Python modules/objects

2007-04-27 Thread Christoph Haas
Dear list,

I have now spent half a day to get omni completion working correctly for
me. Many people say that it just works - others have given up getting it
working. Actually it works as expected with the Python standard library:

import os
os.Ctrl-XCtrl-O

Then I get a choice of objects in the os module. But I don't get any
completion of my own symbols or imported modules. The status line just
reads pattern not found. Do I need to create a ctags file manually?
Can omni completion not complete anything but the standard library?
Right now it's not even close to what I know from IDEs like Wing. I must
have done something wrong because everybody else loves omni completion.
:)

Hints welcome.

 Christoph



RE: Bitchy omni completion with own Python modules/objects

2007-04-27 Thread Mike Hansen
Subject:Bitchy omni completion with own Python modules/objects
From:   Christoph Haas email () christoph-haas ! de
Date:   2007-04-27 8:54:14
Message-ID: 20070427085414.GF3937 () torf ! workaround ! org
[Download message RAW]

Dear list,

I have now spent half a day to get omni completion working correctly
for
me. Many people say that it just works - others have given up getting
it
working. Actually it works as expected with the Python standard
library:

import os
os.Ctrl-XCtrl-O

Then I get a choice of objects in the os module. But I don't get any
completion of my own symbols or imported modules. The status line just
reads pattern not found. Do I need to create a ctags file manually?
Can omni completion not complete anything but the standard library?
Right now it's not even close to what I know from IDEs like Wing. I
must
have done something wrong because everybody else loves omni completion.
:)

Hints welcome.

 Christoph

I have the same problem. It seems to do fine with standard library
modules, but it refuses to look at my own modules or classes. Komodo and
Eclipse w/Pydev seem to handle this, but I can't seem to figure out how
to get VIM to do it or if it is even possible in VIM. More of my code
refers to my own modules than standard library modules.

Mike


dbext omni-completion issue

2006-12-19 Thread Albie Janse van Rensburg

Hi

I am trying to get the (magnificent, by the way) dbext plugin to give
me context-sensitive omni-completion for table/stored procedure names.
It doesn't unfortunately get very far, and when it tries to generate
the dictionary files, I get an error:


dbext: Incorrect syntax near '|'
Msg 102, Level 15, State 1, Server VANRENSBURGA, Line 2



Followed by:


dbext:Failed to create table dictionary


I am using a local MS SQL Server 2005 database.  Other functionality,
such as executing sql statements work fine.  I have two default
configurations set up in my vimrc, for local (development, on
localhost) and a live database (also sql server).

What is the meaning of this error, and what can I do to get completion working?

Regards
Albie Janse van Rensburg


RE: dbext omni-completion issue

2006-12-19 Thread David Fishburn
 I am trying to get the (magnificent, by the way) dbext plugin 
 to give me context-sensitive omni-completion for table/stored 
 procedure names.

Thank you for the praise.

This plugin contains functions/mappings/commands to enable Vim to access
several databases. Currently Mysql, PostgreSQL, Ingres, Oracle, Sybase
Adaptive Server Anywhere, Sybase Adaptive Server Enterprise, Microsoft SQL
Server, DB2, Interbase and SQLite are supported. 


For those of you interested in reading more about dbext:
http://www.vim.org/scripts/script.php?script_id=356



  It doesn't unfortunately get very far, and when it tries to 
 generate the dictionary files, I get an error:
 
  dbext: Incorrect syntax near '|'
  Msg 102, Level 15, State 1, Server VANRENSBURGA, Line 2
 
 
 Followed by:
 
  dbext:Failed to create table dictionary
 
 I am using a local MS SQL Server 2005 database.  Other 
 functionality, such as executing sql statements work fine.  I 
 have two default configurations set up in my vimrc, for local 
 (development, on
 localhost) and a live database (also sql server).


Thank you for reporting the issue.

I have corrected the problem (and tested it) and have uploaded a new version
4.20 to the website.

Enjoy.
Dave




Stack trace - omni completion

2006-10-04 Thread David Fishburn

Vim 7.0 patches 1-106
WinXP SP2

In an attempt to debug one of my scripts, I added some debug statements in
my VimL.  When I did that, Vim will crash and produce the stack trace listed
below.  I can reproduce this every time, and I know the person who reported
the problem (with my script) also gets the crash.

I fired up gvimd.exe (which I compiled) and grabbed the stack trace.  If you
need more information, just let me know.


:ver
VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 14 2006 14:00:05)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-106
Compiled by [EMAIL PROTECTED]
Big version with GUI.  Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info
+comments +cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs -dnd
-ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path
+find_in_path +folding -footer +gettext/dyn -hangul_input +iconv/dyn
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent
+listcmds +localmap +menu +mksession +modify_fname +mouse +mouseshape
+multi_byte +multi_lang -mzscheme +netbeans_intg +ole -osfiletype
+path_extra
+perl/dyn -postscript +printer -profile +python/dyn +quickfix +reltime
+rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline
-sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl
-tgetent -termresponse +textobjects +title +toolbar +user_commands
+vertsplit
+virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu
+windows +writebackup -xfontset -xim -xterm_save +xpm_w32
   system vimrc file: $VIM\vimrc
 user vimrc file: $HOME\_vimrc
 2nd user vimrc file: $VIM\_vimrc
  user exrc file: $HOME\_exrc
  2nd user exrc file: $VIM\_exrc
  system gvimrc file: $VIM\gvimrc
user gvimrc file: $HOME\_gvimrc
2nd user gvimrc file: $VIM\_gvimrc
system menu file: $VIMRUNTIME\menu.vim
Compilation: cl -c /W3 /nologo  -D_MT -MT -I. -Iproto -DHAVE_PATHDEF -DWIN32
-DFEAT_CSCOPE -DFEAT_NETBEANS_INTG   -DFEAT_XPM_W32   -DWINVER=0x0400 -
D_WIN32_WINNT=0x0400  /Fo.\ObjGOLY/ /Ox -DNDEBUG  -DFEAT_OLE -DFEAT_GUI_W32
-DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PYTHON -DDYNAMIC_PYTHON  -DDYNAMI
C_PYTHON_DLL=\python24.dll\ -DFEAT_PERL -DDYNAMIC_PERL
-DDYNAMIC_PERL_DLL=\perl58.dll\ -DFEAT_BIG /Zi /Fd.\ObjGOLY/
Linking: link /RELEASE /nologo /subsystem:windows /incremental:no
/nodefaultlib:libc advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib
uuid.li
b oldnames.lib kernel32.lib gdi32.lib version.lib   winspool.lib
comctl32.lib advapi32.lib shell32.lib  /machine:i386 /nodefaultlib
libcmt.lib oleaut3
2.lib  user32.lib /nodefaultlib:python24.libWSock32.lib
C:\download\OpenSrc\vim\XPM_support_for_Netbeans\xpm-4.2.0\lib\libXpm.lib
/PDB:.\ObjGO
LY/gvim.pdb -debug



AppName: gvimd.exe   AppVer: 7.0.262.0   ModName: gvimd.exe
ModVer: 7.0.262.0Offset: 00072f23


   gvimd.exe!AppendToRedobuffLit(unsigned char * str=0x01938acc, int
len=-1)  Line 546 + 0x9 C
gvimd.exe!ins_compl_prep(int c=67)  Line 3410 + 0xe C
gvimd.exe!edit(int cmdchar=105, int startln=0, long count=1)  Line
773 + 0x12  C
gvimd.exe!invoke_edit(cmdarg_S * cap=0x001268ac, int repl=0, int
cmd=105, int startln=0)  Line 8713 + 0x14   C
gvimd.exe!nv_edit(cmdarg_S * cap=0x001268ac)  Line 8686 + 0x14  C
gvimd.exe!normal_cmd(oparg_S * oap=0x00126900, int toplevel=0)  Line
1137 + 0x10 C
gvimd.exe!exec_normal_cmd(unsigned char * cmd=0x0176e180, int
remap=-1, int silent=0)  Line 9029 + 0xbC
gvimd.exe!ex_normal(exarg * eap=0x00126a14)  Line 8932 + 0x2c   C
gvimd.exe!do_one_cmd(unsigned char * * cmdlinep=0x00126e90, int
sourcing=1, condstack * cstack=0x00126b1c, unsigned char * (int, void *,
int)* getline=0x00437530, void * cookie=0x0012784c)  Line 2613 + 0x16   C
gvimd.exe!do_cmdline(unsigned char * cmdline=0x0176e1d0, unsigned
char * (int, void *, int)* getline=0x00437530, void * cookie=0x0012784c, int
flags=3)  Line 1099 + 0x1f  C
gvimd.exe!ex_execute(exarg * eap=0x00126f38)  Line 18186 + 0x19 C
gvimd.exe!do_one_cmd(unsigned char * * cmdlinep=0x001273b4, int
sourcing=1, condstack * cstack=0x00127040, unsigned char * (int, void *,
int)* getline=0x00437530, void * cookie=0x0012784c)  Line 2613 + 0x16   C
gvimd.exe!do_cmdline(unsigned char * cmdline=0x, unsigned
char * (int, void *, int)* getline=0x00437530, void * cookie=0x0012784c, int
flags=7)  Line 1099 + 0x1f  C
gvimd.exe!call_user_func(ufunc * fp=0x012d68a0, int argcount=2,
typval_T * argvars=0x00127d80, typval_T * rettv=0x00127e7c, long
firstline=1, long lastline=1, dictvar_S * selfdict=0x)  Line 19853 +
0x15C
gvimd.exe!call_func(unsigned char * name=0x01713d60, int len=26,
typval_T * rettv=0x00127e7c, int argcount=2, typval_T * argvars=0x00127d80,
long 

Re: PHP omni-completion, PHP objects

2006-09-05 Thread Mikolaj Machowski
Had to got message from Yahoo Groups, original post was lost somewhere:

 with vim7's omni-completion how do you call/get functions/variables
 relating to a specific class?
 
 $object = new HTML_QuickForm();
 $object-
 
 And then after you type - how do i call for completions only relating
 to the HTML_QuickForm class? I've tried the patch for ctags for PHP5
 but my results are the same, are there specific parameters to build
 the tags file for vim so i can call for suggestions relating to a
 specific class/object? I've been going into my pear/lib dir and
 typing:
 ctags -R
 I've also tried
 ctags -R --fields=+S
 But every time after i type - i will always just get everything in
 the tags file including new class names. Is there a specific key combo
 i must press to get suggestions relating to the class/object?

This one was solved on priv. Implemented new feature, with positive
feedback new version will be sent to Bram to place on ftp.

 Also how can i build a tags file where functions will have parameters
 in the preview window? It already does this for php functions but for
 some reason pear libs and my code will always just be
 function_name()
 instead of
 function_name($param1,$param2,$etc)

Ctags for PHP is very simple and line based. If in PEAR functions are
defined in one line::

function fname($param2, $param1)

It should be extracted by ctags, will be shown in tags file and
omnicompletion plugin should show it in preview window.

Check if generated tags file has similar line::

write_cache cache.php   /^  function write_cache($var, 
$filename) {$/;f

If answer is positive there is probably something wrong with plugin, if
negative check PEAR code or play with ctags options.

m.




PHP omni-completion, PHP objects

2006-09-04 Thread Silent1

Hi all,
with vim7's omni-completion how do you call/get functions/variables
relating to a specific class?

$object = new HTML_QuickForm();
$object-

And then after you type - how do i call for completions only relating
to the HTML_QuickForm class? I've tried the patch for ctags for PHP5
but my results are the same, are there specific parameters to build
the tags file for vim so i can call for suggestions relating to a
specific class/object? I've been going into my pear/lib dir and
typing:
ctags -R
I've also tried
ctags -R --fields=+S
But every time after i type - i will always just get everything in
the tags file including new class names. Is there a specific key combo
i must press to get suggestions relating to the class/object?

Also how can i build a tags file where functions will have parameters
in the preview window? It already does this for php functions but for
some reason pear libs and my code will always just be
function_name()
instead of
function_name($param1,$param2,$etc)

Lastly when you get the list of suggestions, what are the different
keys you can press to cancel the drop down (I've been pressing escape
but then I'm out of insert mode and the suggestion i was on has been
filled in my code). I remember vim's help had the list of keys but i
just can't seem to find it. Thanks in advance.


Re: PHP omni-completion, PHP objects

2006-09-04 Thread A.J.Mechelynck

Silent1 wrote:
[...]

Lastly when you get the list of suggestions, what are the different
keys you can press to cancel the drop down (I've been pressing escape
but then I'm out of insert mode and the suggestion i was on has been
filled in my code). I remember vim's help had the list of keys but i
just can't seem to find it. Thanks in advance.





See
:help ins-completion
:help complete_CTRL-E
:help complete_CTRL-Y
:help popupmenu-completion
:help popupmenu-keys


Best regards,
Tony.


Re: taming omni completion

2006-07-15 Thread Bram Moolenaar

Maciej Kalisiak wrote:

 On 14/07/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
  Please be specific about what kind of scanning needs to finish before it
  notices the typed key.  All types of scans are implemented differently.
  Each should check for a typed key at regular intervals, but if there is
  one that doesn't I need to know which one to be able to look into that.
 
 OK, here's a more detailed rundown:
 - default 'complete' is .,w,b,u,t,i
 - when I hit ^N, I see, on the bottom line in Vim:
 Scanning tags.   (for about 5 seconds)
 Scanning included file: C:\...\file1
 Scanning included file: C:\...\file2
 Scanning included file: C:\...\file3  (each of these included files: ~ 5s)
  ... etc ...

So these are all tags files?  5 seconds is a long time to scan a tags
file.  How big are they?

-- 
hundred-and-one symptoms of being an internet addict:
7. You finally do take that vacation, but only after buying a cellular modem
   and a laptop.

 /// 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: taming omni completion

2006-07-15 Thread Maciej Kalisiak

On 15/07/06, Bram Moolenaar [EMAIL PROTECTED] wrote:


Maciej Kalisiak wrote:

 On 14/07/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
  Please be specific about what kind of scanning needs to finish before it
  notices the typed key.  All types of scans are implemented differently.
  Each should check for a typed key at regular intervals, but if there is
  one that doesn't I need to know which one to be able to look into that.

 OK, here's a more detailed rundown:
 - default 'complete' is .,w,b,u,t,i
 - when I hit ^N, I see, on the bottom line in Vim:
 Scanning tags.   (for about 5 seconds)
 Scanning included file: C:\...\file1
 Scanning included file: C:\...\file2
 Scanning included file: C:\...\file3  (each of these included files: ~ 5s)
  ... etc ...

So these are all tags files?  5 seconds is a long time to scan a tags
file.  How big are they?


No, all the files (except the ./tags file in Scanning tags.) are
Python files, and so is the current file in which I hit ^N.  They are
all less than 1000 lines, and most are less than even 200 lines.

But I've more or less resolved the issue while tweaking Vim on a
different tangent.  The culprit seems to have been too broad a 'path'
variable.  In particular, I've had C:\Python24\Lib\** in 'path',
which is an understandably large subtree, with non-trivial depth and a
lot of branching.  Basically having a foo\** in path, where foo is
any non-trivial directory, brings the whole thing to a crawl.  The
symptoms then are: the insert-completion takes very long to scan the
tags file as well as any included files, and also, :checkpath becomes
terribly slow, printing out a single line per second.

I guess I was just asking too much of Vim.  Now that I've trimmed down
to a more modest 'path', things are going at decent speeds again, even
the scanning of the tags file, incidentally.

The thing I don't quite follow is that, I would expect a broader
'path' setting to merely result in a larger number of files to scan
through in :checkpath or when looking for completions, but not
necessarily affect the scanning time of a single particular file,
which is what I was seeing...


Re: taming omni completion

2006-07-14 Thread Bram Moolenaar

Maciej Kalisiak wrote:

 On 13/07/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
  Hmm, perhaps you are not talking about omni completion but about normal
  Insert mode completion.
 
 Thanks to Hari's post earlier, I now believe so, yes.
 
   This now scans other files sooner than in
  previous versions, so that the menu can be filled.  Note that you don't
  have to wait for this to complete, typing a character will stop it.
 
 Ah, interesting.  The issue for me is that it doesn't really stop
 immediately; it stops at the end of the current scanning stage
 (i.e., it will stop once it *finishes* scanning the current object
 being scanned, be it tags or an actual file).

Please be specific about what kind of scanning needs to finish before it
notices the typed key.  All types of scans are implemented differently.
Each should check for a typed key at regular intervals, but if there is
one that doesn't I need to know which one to be able to look into that.

 This wasn't noticeable
 earlier, or at least it never drew my attention, but now each object
 scan takes somewhere between 2 to 5 seconds, which is odd.  This is
 on a fairly fast machine.  The included Python files, as well as the
 tags file, are fairly simple and short (most 200 lines, a handful
 ~1000 lines; the tags file in current directory has about 1000 lines).
  2 to 5 seconds seems absurdly too much time for said files, no?
 
 Hence, although an improvement, hitting a key immediately after a ^P,
 still takes about 5 seconds to stop... way too much if you're used to
 pressing ^P every 3rd or 4th identifier...
 
 BTW, my previous estimate of the full scan was incorrect; I've never
 had the stomach to wait through the whole thing... I just timed it
 more explicitly, but aborted past the 30 seconds mark... it wasn't
 nearly done 10% of included files...

What is it all scanning then?  Try removing flags from the 'complete'
option one by one to find out which one is taking so much time.

-- 
hundred-and-one symptoms of being an internet addict:
3. Your bookmark takes 15 minutes to scroll from top to bottom.

 /// 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: taming omni completion

2006-07-14 Thread Maciej Kalisiak

On 14/07/06, Bram Moolenaar [EMAIL PROTECTED] wrote:

Please be specific about what kind of scanning needs to finish before it
notices the typed key.  All types of scans are implemented differently.
Each should check for a typed key at regular intervals, but if there is
one that doesn't I need to know which one to be able to look into that.


OK, here's a more detailed rundown:
- default 'complete' is .,w,b,u,t,i
- when I hit ^N, I see, on the bottom line in Vim:
   Scanning tags.   (for about 5 seconds)
   Scanning included file: C:\...\file1
   Scanning included file: C:\...\file2
   Scanning included file: C:\...\file3  (each of these included files: ~ 5s)
... etc ...
- I take it that, by the time (well, it's immediate for me) that I see
the Scanning tags., Vim has already scanned .,w,b,u
- it appears to me that Vim checks for keypresses only between objects
being scanned, when it reaches the t,i elements of 'complete'
- example:
  - I hit ^N
  - immediately the first match is completed in edit window, based on
hits in .,w,b,u
  - immediately I see Scanning tags. on bottom line
  - I then immediately press a key or two
  - nothing happens *until* the 5 seconds have elapsed, and where
normally Vim would proceed to Scanning included file: C:\...\file1,
it terminates the completion
  - if I waited until Scanning included file: C:\...\file1 before
hitting a key, then I would have to wait until that scan was
exhausted, and completion would terminate just before proceeding to
Scanning included file: C:\...\file2
  - the issue is that even the 5s is naturally a long time to wait

- I've since resorted to :set complete=.,w,b,u, and it works like
lightning, like in Vim  7.0; still, it'd be nice to be able to use
the full, default setting.


What is it all scanning then?  Try removing flags from the 'complete'
option one by one to find out which one is taking so much time.


As mentioned above, the slow scanning occurs only on the tags file,
and included files (i.e., the t and i options of 'complete'), which,
as indicated in prior email, are relatively trivial and small.


taming omni completion

2006-07-13 Thread Maciej Kalisiak

I'm using Vim 7.0 on WinXP SP2.  I don't think I did anything specific
to turn on omni-completion (perhaps it's on by default? I'm editing
Python files), and I'm in no rush to start using it, although if it
was non-intrusive I wouldn't mind leaving it on.  The problem is that
I've recently modified my path variable in Vim, and now whenever
omni-completion kicks in -- and it's often -- Vim comes to a lng
stop, 'scanning tags'.  I take it that the scan goes through all files
in my path.  Admittedly my path is now fairly deep:
   let home='C:\Documents\ and\ Settings\Maciek\My\ Documents\Home'
   let path.=','.home.'\python\**'
   let path.=','.home.'\research\**'
   let path.=',c:\Python24\Libs\**'
Probably the last entry is the killer.  Still, I chose to include
these directories/trees in my path as I find the :find command very
useful, much more than the omni-completion; hence if push comes to
shove, I'll ditch omni-complete first.

My question: can anything be done to improve the situation on the
omni-completion front?  Obviously the constant scanning is killing me;
making it faster without sacrificing path variable would be nice.
Also, I'd like to be able to trigger it only when I ask for it, and
not have it automatic.  Also, since I use ctrl-n and ctrl-p a lot to
complete the word under cursor *using only the current file*, I'd
prefer omni-completion to be under a different key combo.

Also, I would've thought omni-completion would use some sort of
caching mechanism, rather than rescanning all the files every single
time.  Doesn't it do that?  Most of the time I hit Ctrl-C to interrupt
the scanning of tags, so I can get on with my work, but I could have
sworn I let it run once or twice to completion before, with no
discernible improvement on subsequent completions...


Re: taming omni completion

2006-07-13 Thread Hari Krishna Dara

On Thu, 13 Jul 2006 at 12:04pm, Maciej Kalisiak wrote:

 I'm using Vim 7.0 on WinXP SP2.  I don't think I did anything specific
 to turn on omni-completion (perhaps it's on by default? I'm editing
 Python files), and I'm in no rush to start using it, although if it
 was non-intrusive I wouldn't mind leaving it on.  The problem is that
 I've recently modified my path variable in Vim, and now whenever
 omni-completion kicks in -- and it's often -- Vim comes to a lng
 stop, 'scanning tags'.  I take it that the scan goes through all files
 in my path.  Admittedly my path is now fairly deep:
 let home='C:\Documents\ and\ Settings\Maciek\My\ Documents\Home'
 let path.=','.home.'\python\**'
 let path.=','.home.'\research\**'
 let path.=',c:\Python24\Libs\**'
 Probably the last entry is the killer.  Still, I chose to include
 these directories/trees in my path as I find the :find command very
 useful, much more than the omni-completion; hence if push comes to
 shove, I'll ditch omni-complete first.

 My question: can anything be done to improve the situation on the
 omni-completion front?  Obviously the constant scanning is killing me;
 making it faster without sacrificing path variable would be nice.
 Also, I'd like to be able to trigger it only when I ask for it, and
 not have it automatic.  Also, since I use ctrl-n and ctrl-p a lot to
 complete the word under cursor *using only the current file*, I'd
 prefer omni-completion to be under a different key combo.

 Also, I would've thought omni-completion would use some sort of
 caching mechanism, rather than rescanning all the files every single
 time.  Doesn't it do that?  Most of the time I hit Ctrl-C to interrupt
 the scanning of tags, so I can get on with my work, but I could have
 sworn I let it run once or twice to completion before, with no
 discernible improvement on subsequent completions...


You are probably talking about the insert-mode completion rather than
the omni-completion. Omni completion is meant is similar to the MS
intellisense, and is not turned on by default. You also need specific
plugins to use that. In contrast, the insert-mode completion is on by
default, and gets triggered when you use ^N, ^P etc. in insert mode.
Also, this completion doesn't use your 'path' but by default your tags
setting, and all the loaded buffers etc. This can be customized by using
the 'complete' option (e.g., you can completely avoid looking into the
tags files). It is possible that you recently added more tags files
which is causing this delay in completion. Actually, without any change
in tags files, I also saw a difference in performance of the insert-mode
completion in Vim7 compared to Vim6.3, and not sure if disabling the
menu will make any difference. You might want to check removing menu
and menuone from 'completeopt' will make any difference (this should
disable popup menu).

Since you mentioned that you find the :find command very useful, might I
put in a plug for my lookupfile.vim plugin? When you use LUPath command,
it cleverly takes advantage of the Vim7 completion menu (which works
even when you disable it in 'completeopt') to lookup matching files as
you type in a partial filename. You can download it from:

http://www.vim.org//script.php?script_id=1581

-- 
HTH,
Hari

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


Re: taming omni completion

2006-07-13 Thread Maciej Kalisiak

On 13/07/06, Hari Krishna Dara [EMAIL PROTECTED] wrote:

You are probably talking about the insert-mode completion rather than
the omni-completion. Omni completion is meant is similar to the MS
intellisense, and is not turned on by default.


Ahhh, I see, yes, I think you're right.

But is there some option which causes it to trigger *automatically*?
Sometimes as I'm midway through typing in a function name or
identifier the popup comes up automatically, without me having pressed
^N...  that's one of the most annoying parts.


In contrast, the insert-mode completion is on by
default, and gets triggered when you use ^N, ^P etc. in insert mode.
Also, this completion doesn't use your 'path' but by default your tags
setting, and all the loaded buffers etc.


Hmm, I noticed the huge performance hit when I extended my path
variable, without having touched my tags, but perhaps Vim in the
background regenerates my tags *based on* my path variable, meaning
it's producing a much larger tags file now...


This can be customized by using
the 'complete' option (e.g., you can completely avoid looking into the
tags files). It is possible that you recently added more tags files
which is causing this delay in completion. Actually, without any change
in tags files, I also saw a difference in performance of the insert-mode
completion in Vim7 compared to Vim6.3, and not sure if disabling the
menu will make any difference. You might want to check removing menu
and menuone from 'completeopt' will make any difference (this should
disable popup menu).


Well, doing 'set completeopt=' (i.e., set it to nothing; previously it
was set to 'preview,menu') seems to speed things up significantly,
although it is still not lightning fast as before.  But we're talking
here a difference of going from 10s to 1s wait times!  The 1s wait is
almost acceptable now.


Since you mentioned that you find the :find command very useful, might I
put in a plug for my lookupfile.vim plugin? When you use LUPath command,
it cleverly takes advantage of the Vim7 completion menu (which works
even when you disable it in 'completeopt') to lookup matching files as
you type in a partial filename. You can download it from:

http://www.vim.org//script.php?script_id=1581


Thanks!  I'll check it out, it sounds very interesting.


Re: taming omni completion

2006-07-13 Thread Hari Krishna Dara

On Thu, 13 Jul 2006 at 1:15pm, Maciej Kalisiak wrote:

 On 13/07/06, Hari Krishna Dara [EMAIL PROTECTED] wrote:
  You are probably talking about the insert-mode completion rather than
  the omni-completion. Omni completion is meant is similar to the MS
  intellisense, and is not turned on by default.

 Ahhh, I see, yes, I think you're right.

 But is there some option which causes it to trigger *automatically*?
 Sometimes as I'm midway through typing in a function name or
 identifier the popup comes up automatically, without me having pressed
 ^N...  that's one of the most annoying parts.

I am not aware of anything that can do this. Which language are you
using? Take a look at the ftplugins for the language and see if it is
doing anything specific to completion.


  In contrast, the insert-mode completion is on by
  default, and gets triggered when you use ^N, ^P etc. in insert mode.
  Also, this completion doesn't use your 'path' but by default your tags
  setting, and all the loaded buffers etc.

 Hmm, I noticed the huge performance hit when I extended my path
 variable, without having touched my tags, but perhaps Vim in the
 background regenerates my tags *based on* my path variable, meaning
 it's producing a much larger tags file now...

As far as I know, Vim doesn't generate tags file, except for the help
documentation. However, I noticed the i and d options in 'complete'
setting which say that Vim scans for all the included files. I don't
know if the files are looked up in the 'path' setting, but you might
having this issue (check if you have these values in 'complete'.


  This can be customized by using
  the 'complete' option (e.g., you can completely avoid looking into the
  tags files). It is possible that you recently added more tags files
  which is causing this delay in completion. Actually, without any change
  in tags files, I also saw a difference in performance of the insert-mode
  completion in Vim7 compared to Vim6.3, and not sure if disabling the
  menu will make any difference. You might want to check removing menu
  and menuone from 'completeopt' will make any difference (this should
  disable popup menu).

 Well, doing 'set completeopt=' (i.e., set it to nothing; previously it
 was set to 'preview,menu') seems to speed things up significantly,
 although it is still not lightning fast as before.  But we're talking
 here a difference of going from 10s to 1s wait times!  The 1s wait is
 almost acceptable now.

Good to know this.


  Since you mentioned that you find the :find command very useful, might I
  put in a plug for my lookupfile.vim plugin? When you use LUPath command,
  it cleverly takes advantage of the Vim7 completion menu (which works
  even when you disable it in 'completeopt') to lookup matching files as
  you type in a partial filename. You can download it from:
 
  http://www.vim.org//script.php?script_id=1581

 Thanks!  I'll check it out, it sounds very interesting.

And please send me your feedback, and don't forget to rate it, if you
like it.

-- 
Thanks,
Hari

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


Re: taming omni completion

2006-07-13 Thread Bram Moolenaar

Maciej Kalisiak wrote:

 I'm using Vim 7.0 on WinXP SP2.  I don't think I did anything specific
 to turn on omni-completion (perhaps it's on by default? I'm editing
 Python files), and I'm in no rush to start using it, although if it
 was non-intrusive I wouldn't mind leaving it on.  The problem is that
 I've recently modified my path variable in Vim, and now whenever
 omni-completion kicks in -- and it's often -- Vim comes to a lng
 stop, 'scanning tags'.  I take it that the scan goes through all files
 in my path.  Admittedly my path is now fairly deep:
 let home='C:\Documents\ and\ Settings\Maciek\My\ Documents\Home'
 let path.=','.home.'\python\**'
 let path.=','.home.'\research\**'
 let path.=',c:\Python24\Libs\**'
 Probably the last entry is the killer.  Still, I chose to include
 these directories/trees in my path as I find the :find command very
 useful, much more than the omni-completion; hence if push comes to
 shove, I'll ditch omni-complete first.

You don't mention what you are actually doing.  Omni completion should
only do something when using CTRL-X CTRL-O in Insert mode.  Otherwise it
should not do anything.  However, it's possible that mappings change
behavior.  Then where does this mapping come from?  Use this to find
out:
:verbose imap

 My question: can anything be done to improve the situation on the
 omni-completion front?  Obviously the constant scanning is killing me;
 making it faster without sacrificing path variable would be nice.
 Also, I'd like to be able to trigger it only when I ask for it, and
 not have it automatic.  Also, since I use ctrl-n and ctrl-p a lot to
 complete the word under cursor *using only the current file*, I'd
 prefer omni-completion to be under a different key combo.

Hmm, perhaps you are not talking about omni completion but about normal
Insert mode completion.  This now scans other files sooner than in
previous versions, so that the menu can be filled.  Note that you don't
have to wait for this to complete, typing a character will stop it.

 Also, I would've thought omni-completion would use some sort of
 caching mechanism, rather than rescanning all the files every single
 time.  Doesn't it do that?  Most of the time I hit Ctrl-C to interrupt
 the scanning of tags, so I can get on with my work, but I could have
 sworn I let it run once or twice to completion before, with no
 discernible improvement on subsequent completions...

Caching would add to the complexity, and Insert mode completion already
is too complex.  It needs to be cleaned up first.

-- 
You have heard the saying that if you put a thousand monkeys in a room with a
thousand typewriters and waited long enough, eventually you would have a room
full of dead monkeys.
(Scott Adams - The Dilbert principle)

 /// 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: taming omni completion

2006-07-13 Thread Hari Krishna Dara

On Thu, 13 Jul 2006 at 10:36pm, Bram Moolenaar wrote:

[snip]

 Hmm, perhaps you are not talking about omni completion but about normal
 Insert mode completion.  This now scans other files sooner than in
 previous versions, so that the menu can be filled.  Note that you don't
 have to wait for this to complete, typing a character will stop it.

My observation is that the time it takes to come up with the first match
is much longer now than before. Previously, the first match used to come
almost immediately, if there is a match in the loaded buffers, and the
scan in external files (tags etc.) used to continue in the background.
Now, I think this is somewhat broken in the sense, I have to wait for
too long for the completion to show up, even though I know there is a
word matching in one of the loaded buffers.

[snip]

-- 
Thanks,
Hari

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


Re: taming omni completion

2006-07-13 Thread Maciej Kalisiak

On 13/07/06, Bram Moolenaar [EMAIL PROTECTED] wrote:

Hmm, perhaps you are not talking about omni completion but about normal
Insert mode completion.


Thanks to Hari's post earlier, I now believe so, yes.


 This now scans other files sooner than in
previous versions, so that the menu can be filled.  Note that you don't
have to wait for this to complete, typing a character will stop it.


Ah, interesting.  The issue for me is that it doesn't really stop
immediately; it stops at the end of the current scanning stage
(i.e., it will stop once it *finishes* scanning the current object
being scanned, be it tags or an actual file).  This wasn't noticeable
earlier, or at least it never drew my attention, but now each object
scan takes somewhere between 2 to 5 seconds, which is odd.  This is
on a fairly fast machine.  The included Python files, as well as the
tags file, are fairly simple and short (most 200 lines, a handful
~1000 lines; the tags file in current directory has about 1000 lines).
2 to 5 seconds seems absurdly too much time for said files, no?

Hence, although an improvement, hitting a key immediately after a ^P,
still takes about 5 seconds to stop... way too much if you're used to
pressing ^P every 3rd or 4th identifier...

BTW, my previous estimate of the full scan was incorrect; I've never
had the stomach to wait through the whole thing... I just timed it
more explicitly, but aborted past the 30 seconds mark... it wasn't
nearly done 10% of included files...


RE: omni completion, calling different types

2006-06-14 Thread David Fishburn
 

 -Original Message-
 From: Silent1 [mailto:[EMAIL PROTECTED] 
 Sent: Monday, June 12, 2006 1:39 PM
 To: vim@vim.org
 Subject: omni completion, calling different types
 
 I'm using the omni completion so far on my php scripts and 
 i'm wondering if there are ways i can call different sets of 
 data with different key strokes.
 
 ctrl-x+ctrl+o will bring up everything and display everything and will
 open up a preview window that has info if a function is 
 called with parameters. How do i get the menu that comes up 
 to display the parameters as well? They come up in the 
 preview window just fine just wondering if i can see them in 
 the drop down menu.
 

This is up to the plugin developer.

The sqlcomplete.vim plugin has been designed to work with other completion
plugins.  Since most programming languages today have some form of access to
a database you still need to be able program SQL.  So regardless whether you
are programming in PHP, Ruby, JSP, VimL you can do the following:
:e file.php
:set ft=sql
:set ft=php

Now the SQL completion is active and can be used in conjunction with the PHP
completion plugin.

It is triggered (while in insert mode) using C-C followed by a key.
The key is what allows you to filter what is displayed in popup window.
The key can be many things:
t - table list
p - procedure list
v - view list
a - all syntax items
k - keywords (for the SQL syntax language)
And so on.


Perhaps Mikolaj could extend the PHP completion plugin in the same manner.

Dave



Re: omni completion, calling different types

2006-06-14 Thread Mikolaj Machowski
Dnia środa, 14 czerwca 2006 17:37, David Fishburn napisał:

 It is triggered (while in insert mode) using C-C followed by a key.
 The key is what allows you to filter what is displayed in popup window.
 The key can be many things:
   t - table list
   p - procedure list
   v - view list
   a - all syntax items
   k - keywords (for the SQL syntax language)
 And so on.


 Perhaps Mikolaj could extend the PHP completion plugin in the same
 manner.

I'd prefer this functionality should be builtin into Vim completion
system as submenus.

m.



Re: omni completion, calling different types

2006-06-13 Thread Mikolaj Machowski
Dnia poniedziałek, 12 czerwca 2006 19:39, Silent1 napisał:
 I'm using the omni completion so far on my php scripts and i'm
 wondering if there are ways i can call different sets of data with
 different key strokes.

You can use 'completefunc' to call different completion script.

 ctrl-x+ctrl+o will bring up everything and display everything and will
 open up a preview window that has info if a function is called with
 parameters. How do i get the menu that comes up to display the
 parameters as well? They come up in the preview window just fine just
 wondering if i can see them in the drop down menu.

No. For many (most?) built in functins popup menu would be too wide.

 Also, everytime i start omni completion with ctrl-x+ctrl+o does it
 research the file again and display everything including the new stuff
 i may have typed?

Part of it.

 If so is there a quicker way to see functions with the parameters
 without reloading the file? ctrl+n will bring up functions but will
 not update the preview window.

No.

 Also is there a way that i can just call php functions with parameters
 and not see functions/classes/variables in the file i'm editing? Also
 the reverse say i would like to only see functions/classes/variables
 in the current file or say just the variables?

No.

m.



Add omni-completion for Python's Base Modules

2006-06-04 Thread Panos Laganakos

Hello,

Is it possible to have omni-completion for python's base modules, like
sys, os etc?

And even more interesting support for any other module installed in
site-packages.

Thanks.


problem using omni completion

2006-06-02 Thread Lonely Rolling Star

I just installed Vim 7 and am attempting to use the new omni completion
feature.  However, it's not working by default; do I have to do something
special to set it up?

:h new-omni-completion states that The 'omnifunc' option is set by
filetype plugins to define the function that figures out the completion. 
Contrariwise, when I open a .js file or .html file, which should have
completion functions defined, the 'omnifunc' option is always empty.

How can I get omni completion working automatically when a file is loaded?
--
View this message in context: 
http://www.nabble.com/problem-using-omni-completion-t1723473.html#a4682013
Sent from the Vim - General forum at Nabble.com.



Re: problem using omni completion

2006-06-02 Thread Lonely Rolling Star

I found a previously supplied answer (see below).

I think some mention of filetype plugin on should really be included in
the help for omni completion.



   E764: Option 'omnifunc' is not set. 

You have to put filetype plugin indent on in your .vimrc file 
(or without the indent part).  Although this function is 
explained elsewhere in the docs, I don't think the omni doc 
itself says that you have to do this.  It mentions that the 
filetype plugins will set omnifunc, but doesn't actually 
mention that you need to tell vim to use these plugins. 
The docs make it sound automatic. 

I had the same problem, and I doubt any new user, nor anyone 
who didn't already know about the :filetype command, would be 
able to figure out how to get it to work. 

--
View this message in context: 
http://www.nabble.com/problem-using-omni-completion-t1723473.html#a4683008
Sent from the Vim - General forum at Nabble.com.



Re: problem using omni completion

2006-06-02 Thread A.J.Mechelynck

Lonely Rolling Star wrote:

I found a previously supplied answer (see below).

I think some mention of filetype plugin on should really be included in
the help for omni completion.



  
  E764: Option 'omnifunc' is not set. 



You have to put filetype plugin indent on in your .vimrc file 
(or without the indent part).  Although this function is 
explained elsewhere in the docs, I don't think the omni doc 
itself says that you have to do this.  It mentions that the 
filetype plugins will set omnifunc, but doesn't actually 
mention that you need to tell vim to use these plugins. 
The docs make it sound automatic. 

I had the same problem, and I doubt any new user, nor anyone 
who didn't already know about the :filetype command, would be 
able to figure out how to get it to work. 


--
View this message in context: 
http://www.nabble.com/problem-using-omni-completion-t1723473.html#a4683008
Sent from the Vim - General forum at Nabble.com.



  
If your vimrc includes source $VIMRUNTIME/vimrc_example.vim (without 
the quotes) it will enable filetype detection, ft-plugin and 
ft-indenting at startup, as well as a lot of other useful settings. (If 
some of them aren't to your liking you can override them later in your 
vimrc.)



Best regards,
Tony.


HTML omni completion not working

2006-05-19 Thread Adam Young

I am having trouble making the html autocomplete thing work in my vim
7. This is the error that I receive: undefined variable b:html_omni
. Autocompletion for other languages (javascript, ruby, etc.) is
working fine. Anyone have any tips?
--
A.T. Young, B.Sc.
Laplink Software / Antibody Design
Vancouver, BC
www.antibodydesign.ca


Re: HTML omni completion not working

2006-05-19 Thread Mikolaj Machowski
Dnia piątek, 19 maja 2006 20:28, Adam Young napisał:
 I am having trouble making the html autocomplete thing work in my vim
 7. This is the error that I receive: undefined variable b:html_omni
 . Autocompletion for other languages (javascript, ruby, etc.) is
 working fine. Anyone have any tips?

What version of htmlcomplete.vim  (Date field in header) ?
And *full* error message please.

m.




Fwd: Question regarding omni completion and ruby

2006-05-15 Thread Robert MannI

Hello!

I'm a very recent VIM convert, I love it.

One question I have: is autocompletion for Ruby built in (in VIM 7),
and how do I use it?

I couldn't find any helpful documentation, maybe someone can give me
some pointers.


Thanks alot,


Robert


Re: Omni-completion howto?

2006-05-09 Thread Aaron Griffin

On 5/8/06, Robert Webb [EMAIL PROTECTED] wrote:

I was also expecting there to be C++ support, but only C
support is provided.  Surely C++ is in wider use than C
these days?  There is a plugin you can download separately
for this however:
http://www.vim.org/scripts/script.php?script_id=1520


There is no c++ support because no one has completed it.  Bram writes
vim in C.  As such, he made the C omnifunc.  C++ is _much_ more
complicated due to namespaces, class hierarchies, static functions,
'this' and many many more things.

Feel free to help out with the C++ omni completion plugin if you'd
like it to work.


RE: Omni-completion problems

2006-05-04 Thread Bram Moolenaar

Robert Webb wrote:

Another issue: it's a bit disconcerting that during insert-mode
completion the cursor goes to the end of the line rather than
staying in correct cursor position.  I am talking about before the
menu appears and millions of file names are speeding past on the
status line.  I'm using gvim on Win2000.
   
   In what situation does this happen?  In the console and with GTK I
   don't see the cursor at all.
  
  I tried it again, and now I can't see the cursor either!  I'm on
  Win2000.  It was definitely there when I tried it before.  Sorry, I
  don't know what's different.
 
 OK, it's happenning again now.  Seems to be when the completion menu
 isn't up yet, ie after a single ^P which finds a match in the current
 file.  No menu appears, and the cursor is still visible but goes to the
 end of the line.

OK, now I see it.  I can probably fix that.

-- 
hundred-and-one symptoms of being an internet addict:
19. All of your friends have an @ in their names.

 /// 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: Omni-completion problems

2006-05-03 Thread Aaron Griffin
My 2 cents - I highly dislike the C-p/C-n use omnicompletion thing. 
When I hit C-p or C-n I *know* that I am using standard vim

completion, and that's what I want.  Just like C-x,C-f or C-x,C-o.  I
know exactly what I'm trying to complete.

The argument I don't want to think about the completion I want is
moot.  If you're writing something that requires omni-completion, you
probably should be thinking.


Re: omni-completion: info bug

2006-04-20 Thread Mikolaj Machowski
Dnia czwartek, 20 kwietnia 2006 13:04, Bram Moolenaar napisał:
 Aaron Griffin wrote:
  Just a heads up:
 
  Using an omni-completion dictionary, a single completion entry (for
  which no menu is displayed) does not update the info preview window.

 Yes, filling the preview window is part of the code for the popup menu.
 If there is only one alternative you don't really need more info to make
 a choice, right?

But old 'info' stays which may lead to misunderstandings.

m.



Re: omni-completion: info bug

2006-04-20 Thread Aaron Griffin
On 4/20/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
 Nice feature, right?  I'll add a remark about that.  The idea is that
 the preview info remains there for a while, so that you can see function
 arguments, for example, while you continue typing.  But if you want to
 explicitly clear it using a space is a good idea.

If I didn't know anything about it, I would expect it to work as follows:

   if length of info text  0, clear window and output text
   else remove preview window

It might be nice to offer two options: '' will kill the preview window
and ' ' would blank it.

Is there any possiblity to get the preview window to pop up for single
completions? If not, I can always force a single empty entry like
{'word':'', 'abbr':'[Cancel]'} or some such oddity...


Re: omni-completion: info bug

2006-04-20 Thread Mikolaj Machowski
Dnia czwartek, 20 kwietnia 2006 17:12, Aaron Griffin napisał:

 On a related note, an 'info' dict entry of '' does not change and/or
 remove the preview information.  Using a single space blanks the
 window, but an empty string does not.

And this is Good Thing :)

m.



Re: omni-completion: info bug

2006-04-20 Thread Mikolaj Machowski
Dnia czwartek, 20 kwietnia 2006 21:59, Aaron Griffin napisał:
 Is there any possiblity to get the preview window to pop up for single
 completions? If not, I can always force a single empty entry like
 {'word':'', 'abbr':'[Cancel]'} or some such oddity...

:help completeopt

menuone flag

m.



Re: omni-completion: info bug

2006-04-20 Thread Mikolaj Machowski
Dnia piątek, 21 kwietnia 2006 00:20, Aaron Griffin napisał:
 Ack, sorry - that was supposed to go to the list

 On 4/20/06, Mikolaj Machowski [EMAIL PROTECTED] wrote:
  Dnia czwartek, 20 kwietnia 2006 17:12, Aaron Griffin napisał:
   On a related note, an 'info' dict entry of '' does not change and/or
   remove the preview information.  Using a single space blanks the
   window, but an empty string does not.
 
  And this is Good Thing :)

 Well here's the way I see it.  If I have completions like so (format
 word:info): abc : 'this is info for abc'
 def : ''
 ghi : 'this is info for ghi'

 Starting on 'abc', you move down to 'def', and the info for 'abc' is
 left in the window.  Fine, that may be intentional.  Moving down to
 'ghi' will switch the info, then moving back up to 'def' will give you
 the wrong info, assuming the 'correct' info was the entry for 'abc'.

Buf if::

def : ' '

Window will be cleared. And that is Good Thing.

m.



Re: suggestions for omni-completion

2006-04-19 Thread Linsong

Alan Briolat wrote:


On Wed, 19 Apr 2006 14:25:42 +0800
Linsong [EMAIL PROTECTED] wrote:

 


Alan Briolat wrote:

   


On Wed, 19 Apr 2006 11:51:31 +0800
Linsong [EMAIL PROTECTED] wrote:



 


Hi,
  I have tried the omni competion, it is very cool!
  But there is still one thing that I think is not very convenient. 
For example, when I input part of a function name(foobar):

foo|  (| is the position of the cursor)
  then I invoke the omnicompletion by pressing C-XC-O, consider 
the completion list like this:
   
fooblah

fooblahblah
fooblahblah
foobar
...
...

then the strings inputed will be replaced by the first matched item(here 
it is fooblah). If I want to get foobar, I need to press C-N several 
times. It is not very convenient.
  
   I think it would be better like the following:
   After C-XC-O, the inputed string will not be replaced, only the 
completion menu shows up, then I can choose the item that I want by 
pressing C-N; Or, I can go on to input more characters and the 
completion menu will update its menu items based on the new input when I 
input. So the items in completion menu will become less and less and it 
is easier to select the matched item. Inputing more characters is better 
than pressing C-N several times.
  

   


I *believe* this is the purpose of C-XC-OC-P (someone please correct me
if I am wrong...)


 


Yes, that is just what I mean. I need to go over the online help :)
Do you know how to make it as the default action, that is make 
C-XC-O works like C-XC-OC-P?
   



Well, what I do is map a different key sequence to it.  My preference (doesn't
work in terminals though) is:
:imap C-space C-XC-OC-P

There appears to be only one problem with using C-XC-OC-P, which is that
it makes omni-complete useless when there is only one match (doesn't replace,
and doesn't give a list of options). If someone knows how to overcome this,
please let me know :(
 

I suggest vim to provide a option that don't modify the inputed 
character when pressing C-XC-O.


BR
Vincent



omni-completion: info bug

2006-04-19 Thread Aaron Griffin
Just a heads up:

Using an omni-completion dictionary, a single completion entry (for
which no menu is displayed) does not update the info preview window.

Thanks,
Aaron Griffin


Re: suggestions for omni-completion

2006-04-19 Thread Linsong

Alan Briolat wrote:


On Wed, 19 Apr 2006 11:51:31 +0800
Linsong [EMAIL PROTECTED] wrote:

 


Hi,
   I have tried the omni competion, it is very cool!
   But there is still one thing that I think is not very convenient. 
For example, when I input part of a function name(foobar):

 foo|  (| is the position of the cursor)
   then I invoke the omnicompletion by pressing C-XC-O, consider 
the completion list like this:

 fooblah

 fooblahblah
 fooblahblah
 foobar
 ...
 ...

then the strings inputed will be replaced by the first matched item(here 
it is fooblah). If I want to get foobar, I need to press C-N several 
times. It is not very convenient.
   
I think it would be better like the following:
After C-XC-O, the inputed string will not be replaced, only the 
completion menu shows up, then I can choose the item that I want by 
pressing C-N; Or, I can go on to input more characters and the 
completion menu will update its menu items based on the new input when I 
input. So the items in completion menu will become less and less and it 
is easier to select the matched item. Inputing more characters is better 
than pressing C-N several times.
   



I *believe* this is the purpose of C-XC-OC-P (someone please correct me
if I am wrong...)
 


Yes, that is just what I mean. I need to go over the online help :)
Do you know how to make it as the default action, that is make 
C-XC-O works like C-XC-OC-P?


Thanks a lot!

BR
Vincent

 

Hope I have described my idea clearly. In fact, it is not my idea, 
it is the design of Visual Assistant(visit http://www.wholetomato.com/ 
for more details, there are some animations ), you can try it if you 
have a windows box and visual studio installed.


BR
Vincent
  
  
   




 





Re: suggestions for omni-completion

2006-04-19 Thread Alan Briolat
On Wed, 19 Apr 2006 14:25:42 +0800
Linsong [EMAIL PROTECTED] wrote:

 Alan Briolat wrote:
 
 On Wed, 19 Apr 2006 11:51:31 +0800
 Linsong [EMAIL PROTECTED] wrote:
 
   
 
 Hi,
 I have tried the omni competion, it is very cool!
 But there is still one thing that I think is not very convenient. 
 For example, when I input part of a function name(foobar):
   foo|  (| is the position of the cursor)
 then I invoke the omnicompletion by pressing C-XC-O, consider 
 the completion list like this:
  
   fooblah
   fooblahblah
   fooblahblah
   foobar
   ...
   ...
 
 then the strings inputed will be replaced by the first matched item(here 
 it is fooblah). If I want to get foobar, I need to press C-N several 
 times. It is not very convenient.
 
  I think it would be better like the following:
  After C-XC-O, the inputed string will not be replaced, only the 
 completion menu shows up, then I can choose the item that I want by 
 pressing C-N; Or, I can go on to input more characters and the 
 completion menu will update its menu items based on the new input when I 
 input. So the items in completion menu will become less and less and it 
 is easier to select the matched item. Inputing more characters is better 
 than pressing C-N several times.
 
 
 
 I *believe* this is the purpose of C-XC-OC-P (someone please correct me
 if I am wrong...)
   
 
 Yes, that is just what I mean. I need to go over the online help :)
 Do you know how to make it as the default action, that is make 
 C-XC-O works like C-XC-OC-P?

Well, what I do is map a different key sequence to it.  My preference (doesn't
work in terminals though) is:
:imap C-space C-XC-OC-P

There appears to be only one problem with using C-XC-OC-P, which is that
it makes omni-complete useless when there is only one match (doesn't replace,
and doesn't give a list of options). If someone knows how to overcome this,
please let me know :(

 
 Thanks a lot!
 
 BR
 Vincent
 
   
 
  Hope I have described my idea clearly. In fact, it is not my idea, 
 it is the design of Visual Assistant(visit http://www.wholetomato.com/ 
 for more details, there are some animations ), you can try it if you 
 have a windows box and visual studio installed.
  
 BR
 Vincent


 
 
 
 
   
 
 


-- 
Alan Briolat [EMAIL PROTECTED]http://www.dotphp.org/
Haha, I just wasted 76 bytes of your bandwidth! How does that make you feel?


Re: suggestions for omni-completion

2006-04-19 Thread Linsong

Alan Briolat wrote:


On Wed, 19 Apr 2006 14:25:42 +0800
Linsong [EMAIL PROTECTED] wrote:

 


Alan Briolat wrote:

   


On Wed, 19 Apr 2006 11:51:31 +0800
Linsong [EMAIL PROTECTED] wrote:



 


Hi,
  I have tried the omni competion, it is very cool!
  But there is still one thing that I think is not very convenient. 
For example, when I input part of a function name(foobar):

foo|  (| is the position of the cursor)
  then I invoke the omnicompletion by pressing C-XC-O, consider 
the completion list like this:
   
fooblah

fooblahblah
fooblahblah
foobar
...
...

then the strings inputed will be replaced by the first matched item(here 
it is fooblah). If I want to get foobar, I need to press C-N several 
times. It is not very convenient.
  
   I think it would be better like the following:
   After C-XC-O, the inputed string will not be replaced, only the 
completion menu shows up, then I can choose the item that I want by 
pressing C-N; Or, I can go on to input more characters and the 
completion menu will update its menu items based on the new input when I 
input. So the items in completion menu will become less and less and it 
is easier to select the matched item. Inputing more characters is better 
than pressing C-N several times.
  

   


I *believe* this is the purpose of C-XC-OC-P (someone please correct me
if I am wrong...)


 


Yes, that is just what I mean. I need to go over the online help :)
Do you know how to make it as the default action, that is make 
C-XC-O works like C-XC-OC-P?
   



Well, what I do is map a different key sequence to it.  My preference (doesn't
work in terminals though) is:
:imap C-space C-XC-OC-P

There appears to be only one problem with using C-XC-OC-P, which is that
it makes omni-complete useless when there is only one match (doesn't replace,
and doesn't give a list of options). If someone knows how to overcome this,
please let me know :(
 

I suggest vim to provide a option that don't modify the inputed 
character when pressing C-XC-O.


BR
Vincent



Re: Why python omni-completion work incorrect in vim7.0e1 and vim7.0e2?

2006-04-19 Thread Linsong

Bram Moolenaar wrote:


Zhang Yi wrote:

 


 pythoncomplete works fine in vim7.0e, but in vim7.0e1 and vim7.0e2, when I
press C-x C-o, error reported and no completion list displayed.
 I use Same compile environment and command under Win XP SP2.
   



I don't see anything that changed specifically for Python completion.

What error is reported?  Did you compile Vim with Python support?
 


Hi,
   I wonder if the pycomplete.py realy works, when I try the following 
case, it gives me some errors:


 def test(a, b):
 return a+b
 if __name__==__main__:
 tesC-XC-O
 


BR
Vincent



Re: Why python omni-completion work incorrect in vim7.0e1 and vim7.0e2?

2006-04-19 Thread Linsong

Linsong wrote:


ice_2001cn wrote:



Linsong wrote:


Bram Moolenaar wrote:


Zhang Yi wrote:

 

 pythoncomplete works fine in vim7.0e, but in vim7.0e1 and 
vim7.0e2, when I

press C-x C-o, error reported and no completion list displayed.
 I use Same compile environment and command under Win XP SP2.
  




I don't see anything that changed specifically for Python completion.

What error is reported?  Did you compile Vim with Python support?
 


Hi,
   I wonder if the pycomplete.py realy works, when I try the 
following case, it gives me some errors:


 def test(a, b):
 return a+b
 if __name__==__main__:
 tesC-XC-O
 


BR
Vincent 



  def test(a, b):
  return a+b
  if __name__==__main__:
  tesC-XC-O


At this time, use c-xc-p or c-xc-n instead of c-xc-o
^_^
For completion a function defined in the same file . Use c-xc-n
c-xc-p . It's the same for c/c++,java,php .



If this is true, then I think it is a bad design :(

And I just tried the following codes, it give me some errors then the 
completion list menu shows up:


   import os
   if __name__==__main__:
  os.C-XC-O

BR
Vincent

   I just read the manual of completeopt, I think if there is 'menu' in 
the completeopt, then Enter should insert the selected menu item 
instead of insert a new line; else, there is no 'menu' in the 
completeopt, Enter starts a new line.

   I think this is more reasonalbe.

BR
Vincent




Omni completion file naming

2006-04-12 Thread Doug Kearns
I assume the omni completion files should follow the same naming
convention as the other runtime files? Eg. Should the current
pycomplete.vim actually be named pythoncomplete.vim?

Regards,
Doug


Re: Omni completion file naming

2006-04-12 Thread Nikolai Weibull
On 4/12/06, Doug Kearns [EMAIL PROTECTED] wrote:
 I assume the omni completion files should follow the same naming
 convention as the other runtime files? Eg. Should the current
 pycomplete.vim actually be named pythoncomplete.vim?

I don't know how they're stored now, but shouldn't it be complete/python.vim?

  nikolai