Python/Ruby completion requires language interface ?
Hello developers, I notice that the scripts autoload/pythoncomplete.vim and autoload/rubycomplete.vim terminate early and with error if the corresponding interface is not compiled-in. Is that intentional? I would expect to be able to _edit_ (for instance) a python script even on a Vim version which cannot _run_ python commands. Note: The ruby script mentions Maintainer: Mark Guzman [EMAIL PROTECTED]. I'm not emailing that address. Best regards, Tony.
better user-definition of paragraphs
Hi all,
playing with formatoptions+=a I stumbled on the 'paragraphs' option
and I must confess I feel it's quite dumb (probably due to compatibility
issue with old vi? don't know ...)
My main problem is that I want a way to define where paragraphs start,
... even if I'm not writing nroff! Two use cases that may clarify my
needs:
1) TeX
I want to tell vim that a line starting with ^\s*\\ (a TeX macro at
the beginning of a line) marks a new paragraph. This way vim with
automatic formatting wont try to change the following:
\begin{itemize}
\item foo
\item bar
\end{itemize}
in the following:
\begin{itemize} \item foo \item bar \end{itemize}
2) Mail
Similarly, I usually write mails in mutt editing headers. I want to
tell vim that a line starting with ^\u\U+: (an header name at the
beginning of a line) marks a new paragraphs. Such that the following:
From: Stefano Zacchiroli [EMAIL PROTECTED]
To: VIM Development List vim-dev@vim.org
Subject: better user-definition of paragraphs
is not changed to:
From: Stefano Zacchiroli [EMAIL PROTECTED] To: VIM Development List
vim-dev@vim.org Subject: better user-definition of paragraphs
I'm a bit puzzled that there is no support for that, maybe I am missing
something? No one else has ever wanted such a feature?
Thanks in advance,
Cheers.
--
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-
Re: Python/Ruby completion requires language interface ?
Dnia środa, 27 września 2006 11:35, A.J.Mechelynck napisał: I notice that the scripts autoload/pythoncomplete.vim and autoload/rubycomplete.vim terminate early and with error if the corresponding interface is not compiled-in. Is that intentional? I would expect to be able to _edit_ (for instance) a python script even on a Vim version which cannot _run_ python commands. I don't agree with that. If interface is required for good completion it should be done using that interface. But even in such situation good degrading of script behaviour is required. Crashing IMO is unacceptable. m.
Re: Python/Ruby completion requires language interface ?
The script terminates, not vim...
if !has('python')
echo Error: Required vim compiled with +python
finish
endif
is right at the start.
Regards,
Stefan
Re: Non-intuitive default behaviour of gI
On Tue, Sep 26, 2006 at 09:14:46PM -0700, Gautam Iyer wrote: Hi All, I noticed that pressing gI inserts text at column 1 of the current line (as documented in the help). However given the commands gj and gk, wouldn't it be more intuitive to have gI insert text at the first screen column? I guess I can just do nmap gI g0i in my ~/.vimrc, but I though I would point out the inconsistent behaviour. Unless I am missing something, the current meaning of gI is not very useful. Is there any difference between [count]gI and 0[count]i ? (Note that both have the same number of key strokes.) Unfortunately, I think it is too late to change it to something like g0i, which would save a key stroke. I am not convinced by the consistency argument. IIUC, g is not a Normal-mode command in traditional vi (and it may be the only alphabetic character with this distinction.) Thus g is used in vim for a wide variety of commands, with gchar usually meaning some variant of char. See :help g for a list. HTH --Benji Fisher
Re: vim is scrambling my files
i tried ctr-L, i tired vim 7 but no luck. it seems to be only this file that
is affected. i think it might have to do with this file being open when my
computer crashed. i believe there is a .swp file of the same name in the
same directory. not sure if thats relevant
Peter Hodge-3 wrote:
Just my 2c worth, is it a display problem that goes away when you press
CTRL+L?
regards,
Peter
--- jinxjinx [EMAIL PROTECTED] wrote:
:verbose set makeprg? makeef? autowrite? autowriteall?
makeprg=make
makeef=
noautowrite
noautowriteall
:verbose setlocal filetype?
filetype=c
Las set from /usr/share/vim/vim64/filetype.vim
:version
VIM - Vi IMproved 6.4 (2005 Oct 15, compiled May 23 2006 12:03:57)
Included patches: 1-6
Compiled by [EMAIL PROTECTED]
Big version without 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 +dialog_con +diff +digraphs -dnd -ebcdic +emacs_tags
+eval
+ex_extra +extra_search +farsi +file_in_path +find_in_path +folding
-footer
+fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap
+langmap
+libcall +linebreak +lispindent +listcmds +localmap +menu +mksession
+modify_fname +mouse -mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm
+mouse_netterm +mouse_xterm +multi_byte +multi_lang -netbeans_intg
-osfiletype
+path_extra -perl +postscript +printer -python +quickfix +rightleft -ruby
+scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax
+tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse
+textobjects +title -toolbar +user_commands +vertsplit +virtualedit
+visual
+visualextra +viminfo +vreplace +wildignore +wildmenu +windows
+writebackup
-X11
-xfontset -xim -xsmp -xterm_clipboard -xterm_save
system vimrc file: $VIM/vimrc
user vimrc file: $HOME/.vimrc
user exrc file: $HOME/.exrc
fall-back for $VIM: /usr/share/vim
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -g -Wall
Linking: gcc -L/usr/local/lib -o vim -lncurses -lgpm
:echo current_compiler did not work
the scrambled colum is a column of characters that match what ever
character
is next to it
or sometimes just copys of text from other parts of the file.
thanks for the responce
A.J.Mechelynck wrote:
jinxjinx wrote:
when i do a save and then a make, for somereason my file gets
scrambled.
vim
adds a colum of letters. and i get all these compile errors. so i quit
without saving, and the extra letters go away! what could be going on
here?
here is my vimrc
syn region myFold start={ end=} transparent fold
syn sync fromstart
set foldmethod=syntax
set nowrap
set mouse=a
also when i get into vim i do :syntax on
What are the first 3 or 4 lines of the reply to :version [until and
including Features included (+) or not (-):]? (To copy the whole
:version
output to the clipboard, use:
:set nomore
:redir @*
:version
:redir END
:set more
:let @+ = @*
[the last line above is not necessary on Windows]. You can trim the
result
after pasting it into an email.)
What does Vim answer to the following? (entered with the question
marks,
and
with the problematic source file, not some help file, being current)
:verbose set makeprg? makeef? autowrite? autowriteall?
:verbose setlocal filetype?
:echo current_compiler
What does that column of letters look like? Any recognizable pattern?
Could
you paste an example into an email? (To copy the whole editfile to the
clipboard, use [in Normal mode] ggVG followed by +y -- assuming that
your
version of Vim has access to the clipboard).
Best regards,
Tony.
--
View this message in context:
http://www.nabble.com/vim-is-scrambling-my-files-tf2336221.html#a6519686
Sent from the Vim - Dev mailing list archive at Nabble.com.
On Yahoo!7
Check back weekly for Trixi's new online adventures
http://www.trixi.com.au
--
View this message in context:
http://www.nabble.com/vim-is-scrambling-my-files-tf2336221.html#a6532330
Sent from the Vim - Dev mailing list archive at Nabble.com.
Re: Python/Ruby completion requires language interface ?
Dnia środa, 27 września 2006 14:27, Stefan Walk napisał:
The script terminates, not vim...
if !has('python')
echo Error: Required vim compiled with +python
finish
endif
is right at the start.
It could at least degrade to syntax highlighting completion.
m.
Re: Python/Ruby completion requires language interface ?
Mark Guzman wrote:
A.J.Mechelynck wrote:
I notice that the scripts autoload/pythoncomplete.vim and
autoload/rubycomplete.vim terminate early and with error if the
corresponding interface is not compiled-in. Is that intentional? I
would expect to be able to _edit_ (for instance) a python script even
on a Vim version which cannot _run_ python commands.
if !has('ruby')
s:ErrMsg( Error: Required vim compiled with +ruby )
finish
endif
if version 700
s:ErrMsg( Error: Required vim = 7.0 )
finish
endif
Vim continues to run.
--mark
Yes, I never said anything else: ...the scripts... terminate early and with
error It surprised me because, after all, Vim doesn't need to be a C
compiler to run ccomplete.vim, or a Web browser (hiding tags, the whole HEAD
part, and OTOH showing clickable A HREF=... links and graphical IMG
pictures) to use htmlcomplete.vim. Executing a script and editing it are two
different things.
Best regards,
Tony.
P.S. Is that really your mail address? Looks bogus to me. But then if it were,
you shouldn't stay long on the mailing list...
Re: no winclose event
Charles E Campbell Jr wrote: Bram Moolenaar wrote: Charles Campbell wrote: Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave would almost do, but if two or more windows are open on the same buffer, then no event. WinLeave fires whenever one changes windows, which isn't what I want, either. Unless I'm misunderstanding the help for these two events. What would this event be used for? The WinResized event has also been suggested. It could be used to update the Window layout. It will also be triggered when a window is closed, since another window will get bigger then. Would it be sufficient to only have a WinResized event? Would these events also be triggered when closing the last window of a tab page? As an example: I have debugging output in a left hand window (Decho.vim produces this sort of output); when I hit f9 on a function name, a vertically split window shows up on the right and tags to the named function. However, if that window already exists, I just want to re-use it, not split and create another one. To do that correctly, I need that window, when it is actually closed, to perform some cleanup (ie. make a change in a script variable). I want to allow other vertical windows, so there isn't necessarily a fixed number of vertically split panes. Actually, the script also allows s-f9 to create a left hand source window: [leftsource|debugging|rightsource]. The leftsource and right source windows may well be open to the same source file. Consequently the various buffer closing events aren't adequate. BufWinLeave almost does the trick, but there's that not when a buffer is still visible in another window caveat associated with it. That's what I've been using, but it really isn't adequate. A WinResized might easily occur when that window wasn't closed, too. Regards, Chip Campbell Yes, and it would happen on the resized windows, not the one which was closed, but at least you could (if it existed) use it to check whether your windows (which require cleanup) are still open. Or else, closing a window might be regarded as resizing it to size -1 (size 0 is window present, but not active, and showing only the status line). I suppose that if WinResize gets implemented, when resizing by dragging the mouse it should trigger when releasing the mouse button, not as soon as the status line moves, in order to avoid multiple triggerings when resizing by more than one line; and I wonder: if 'equalalways' is set, it would trigger for every window whenever a window (including a help window) is opened or closed... Or else, have it trigger only once, amatch wouldn't be significant then, and it would be the autocommand responsibility to check which window was resized. Best regards, Tony.
Re: no winclose event
Bram Moolenaar wrote: Charles Campbell wrote: Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave would almost do, but if two or more windows are open on the same buffer, then no event. WinLeave fires whenever one changes windows, which isn't what I want, either. Unless I'm misunderstanding the help for these two events. What would this event be used for? The WinResized event has also been suggested. It could be used to update the Window layout. It will also be triggered when a window is closed, since another window will get bigger then. Would it be sufficient to only have a WinResized event? Would these events also be triggered when closing the last window of a tab page? Also, if I may point out, concerning the patch I wrote: The WinClose event took but little extra code to install. Basically, a line to define an EVENT_WINCLOSE, a line to map WinClose to EVENT_WINCLOSE, and a single apply_event() call. OTOH, the patch portion for WinResize involved several more places. As is, there'll be at least two WinResize events when a ctrl-w= (all windows equal sized) is used (one for the vertical, one for the horizontal, resize). You're bound to get someone who wants a VertWinResize and a HorzWinResize (but we can ignore s/he, right?) :) . Plus, I didn't figure out where the mouse-drag resize occurred, so that'd be yet another apply_event(). Seems like that is buried in the gui*.c code, so several drivers would be affected. Not that I'd expect that it'd take but one or two apply_event() calls in each such file. I'm just pointing out that WinClose is simpler than WinResize. BTW, what function in gui_x11.c is doing the window-resizing due to mouse dragging? Curiosity is killing me! :0 Regards, Chip Campbell
Re: vim is scrambling my files
jinxjinx wrote: i tried ctr-L, i tired vim 7 but no luck. it seems to be only this file that is affected. i think it might have to do with this file being open when my computer crashed. i believe there is a .swp file of the same name in the same directory. not sure if thats relevant [...] There is (almost) always a .swp file present while you're editing the file. If Vim finds one when opening the file, you'll get a long message and a choice of options (see :help ATTENTION). Best regards, Tony.
[Fwd: Re: Many GVIM locale problems fixed; one remains]
I got the attached email privately. I guess it should have gone to the list
and/or to Yongwei.
Best regards,
Tony.
---BeginMessage---
Hi Antoine,
On 9/26/06, A.J.Mechelynck [EMAIL PROTECTED] wrote:
Yongwei Wu wrote:
[...]
It looks like a UTF-8 string is displayed as a GBK string. I confirmed
it by (in a CP936 console):
$ echo 关闭标签|iconv -f cp936 -t utf-8
��抽�绛�
The resulting string is exactly what I get in UTF-8 mode. (There are
4*3/2 = 6 characters, but you may only see 5 since 0xADBE is not a
valid code point for GBK.)
[...]
I see six, which translate into UTF-8 as U+934F U+62BD U+68F4 U+93CD U+56E9
U+E137, i.e. �� wéi (undefined), 抽 chōu (to pull out), �� fú (undefined), ��
lúo (undefined, but traditional for U+9559 镙, also undefined), �� yùn
(undefined) and (E137: not found in Unihan database; U+E000-U+F8FF is a
Private area range; Thunderbird displays the corresponding GB2312 character
with the same glyph as U+5E09 �� fēn, undefined). Transliterations above
represent the Mandarin reading according to the pinyin representation.
The original string, guānbì biāoqiān, might mean close tab or something like
that (the individual ideograms seem to mean close-lock-label-paper slip but
from the context it can only be one of close tab new tab or open tab...
:-) ).
Can you try the attached patch to see whether this problem is
fixed or not? The patch is against the latest Vim7 version from CVS.
I am not familiar with Unicode and I don't have a setup to test the fix
for this issue.
Thanks,
Yegappan
Index: src/gui_w48.c
===
RCS file: /cvsroot/vim/vim7/src/gui_w48.c,v
retrieving revision 1.36
diff -c -p -r1.36 gui_w48.c
*** src/gui_w48.c 29 Aug 2006 19:26:10 - 1.36
--- src/gui_w48.c 27 Sep 2006 17:20:31 -
*** gui_mch_show_toolbar(int showit)
*** 2217,2226
#if defined(FEAT_GUI_TABLINE) || defined(PROTO)
static void
show_tabline_popup_menu(void)
{
HMENU tab_pmenu;
- MENUITEMINFOminfo;
long rval;
POINT pt;
--- 2217,2273
#if defined(FEAT_GUI_TABLINE) || defined(PROTO)
static void
+ add_tabline_popup_menu_entry(pmenu, item_id, item_text)
+ HMENU pmenu;
+ UINT item_id;
+ char_u *item_text;
+ {
+ #ifdef FEAT_MBYTE
+ WCHAR *wn = NULL;
+ int n;
+
+ if (enc_codepage = 0 (int)GetACP() != enc_codepage)
+ {
+ /* 'encoding' differs from active codepage: convert menu name
+ * and use wide function */
+ wn = enc_to_ucs2(item_text, NULL);
+ if (wn != NULL)
+ {
+ MENUITEMINFOW infow;
+
+ infow.cbSize = sizeof(infow);
+ infow.fMask = MIIM_TYPE | MIIM_ID;
+ infow.wID = item_id;
+ infow.fType = MFT_STRING;
+ infow.dwTypeData = wn;
+ infow.cch = (UINT)wcslen(wn);
+ n = InsertMenuItemW(pmenu, item_id, FALSE, infow);
+ vim_free(wn);
+ if (n == 0 GetLastError() == ERROR_CALL_NOT_IMPLEMENTED)
+ /* Failed, try using non-wide function. */
+ wn = NULL;
+ }
+ }
+
+ if (wn == NULL)
+ #endif
+ {
+ MENUITEMINFO info;
+
+ info.cbSize = sizeof(info);
+ info.fMask = MIIM_TYPE | MIIM_ID;
+ info.wID = item_id;
+ info.fType = MFT_STRING;
+ info.dwTypeData = item_text;
+ info.cch = (UINT)STRLEN(item_text);
+ InsertMenuItem(pmenu, item_id, FALSE, info);
+ }
+ }
+
+ static void
show_tabline_popup_menu(void)
{
HMENU tab_pmenu;
long rval;
POINT pt;
*** show_tabline_popup_menu(void)
*** 2236,2256
if (tab_pmenu == NULL)
return;
! minfo.cbSize = sizeof(MENUITEMINFO);
! minfo.fMask = MIIM_TYPE|MIIM_ID;
! minfo.fType = MFT_STRING;
!
! minfo.dwTypeData = _(Close tab);
! minfo.wID = TABLINE_MENU_CLOSE;
! InsertMenuItem(tab_pmenu, TABLINE_MENU_CLOSE, FALSE, minfo);
!
! minfo.dwTypeData = _(New tab);
! minfo.wID = TABLINE_MENU_NEW;
! InsertMenuItem(tab_pmenu, TABLINE_MENU_NEW, FALSE, minfo);
!
! minfo.dwTypeData = _(Open tab...);
! minfo.wID = TABLINE_MENU_OPEN;
! InsertMenuItem(tab_pmenu, TABLINE_MENU_OPEN, FALSE, minfo);
GetCursorPos(pt);
rval = TrackPopupMenuEx(tab_pmenu, TPM_RETURNCMD, pt.x, pt.y, s_tabhwnd,
--- 2283,2292
if (tab_pmenu == NULL)
return;
! add_tabline_popup_menu_entry(tab_pmenu, TABLINE_MENU_CLOSE, _(Close tab));
! add_tabline_popup_menu_entry(tab_pmenu, TABLINE_MENU_NEW, _(New tab));
! add_tabline_popup_menu_entry(tab_pmenu, TABLINE_MENU_OPEN,
! _(Open tab...));
GetCursorPos(pt);
rval = TrackPopupMenuEx(tab_pmenu, TPM_RETURNCMD, pt.x, pt.y, s_tabhwnd,
---End Message---
matchparen highlight bug
Hello.
I've found bug in highlighting when matchparen is used. Not sure it is
because of a matchparen thought.
Test case
=
gvim
i{}EschO
Now I can see first line with one character background been highlighted
and an insert cursor over it and '{}' on a second line, both highlighted.
Not sure how to reproduce this on -u NONE -U NONE...
VIM - Vi IMproved 7.0 (2006 May 7, compiled Sep 22 2006 22:03:35)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-109
Compiled by [EMAIL PROTECTED]
Huge 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 -postscript
+printer
+profile -python +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 -D_DLL -MDd -I. -Iproto
-DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG
-DWINVER=0x0500 -D_WIN32_WINNT=0x0500 /Fo.\ObjGOd/ -D_DEBUG -DDEBUG /Od
-MDd -DFEAT_OLE -DFEAT_MBYTE -DFEAT_GUI_W32 -DDYNAMIC_ICONV
-DDYNAMIC_GETTEXT -DFEAT_HUGE /Zi /Fd.\ObjGOd/
Linking: link /DEBUG /DEBUGTYPE:cv /nologo /subsystem:windows
/incremental:no /nodefaultlib:libc advapi32.lib shell32.lib gdi32.lib
comdlg32.lib ole32.lib uuid.lib oldnames.lib kernel32.lib gdi32.lib
version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib
/machine:i386 /nodefaultlib /fixed:no msvcrtd.lib oleaut32.lib
user32.lib WSock32.lib /PDB:.\ObjGOd/gvimd.pdb -debug
DEBUG BUILD
Re: Python/Ruby completion requires language interface ?
A.J.Mechelynck wrote: Yes, I never said anything else: ...the scripts... terminate early and with error It surprised me because, after all, Vim doesn't need to be a C compiler to run ccomplete.vim, or a Web browser (hiding tags, the whole HEAD part, and OTOH showing clickable A HREF=... links and graphical IMG pictures) to use htmlcomplete.vim. Executing a script and editing it are two different things. My other message covered the reason for the requirement. C as a language does not provide introspection, python and ruby do. The most effective completion (for ruby) comes from asking the ruby interpreter itself what do you know about X. I will probably add a fail-over to syntax completion as someone else mentioned. I wonder how microsoft manages their completion system, I'm of the belief that they are also using introspection (probably in some sort of sandbox). It would be nice if I could access the spelling/underlining stuff to provide syntax error information. I haven't look too hard yet to see if this is possible, but I for one would find it useful. P.S. Is that really your mail address? Looks bogus to me. But then if it were, you shouldn't stay long on the mailing list... Yes, it is indeed my email address, though I have a few aliases that are a bit more formal. I am quite the trouble maker. I'm sure you can imagine that my address does not validate on many websites, apparently .info domains aren't valid in most peoples eyes. --mark -- sic transit gloria et adulescentia blog | http://blog.hasno.info/blog wiki | http://wiki.hasno.info
Re: Python/Ruby completion requires language interface ?
On 9/27/06, Mark Guzman [EMAIL PROTECTED] wrote: A.J.Mechelynck wrote: Yes, I never said anything else: ...the scripts... terminate early and with error It surprised me because, after all, Vim doesn't need to be a C compiler to run ccomplete.vim, or a Web browser (hiding tags, the whole HEAD part, and OTOH showing clickable A HREF=... links and graphical IMG pictures) to use htmlcomplete.vim. Executing a script and editing it are two different things. My other message covered the reason for the requirement. C as a language does not provide introspection, python and ruby do. The most effective completion (for ruby) comes from asking the ruby interpreter itself what do you know about X. I will probably add a fail-over to syntax completion as someone else mentioned. I wonder how microsoft manages their completion system, I'm of the belief that they are also using introspection (probably in some sort of sandbox). For obvious reasons, I'm going to side with Mark here. You can claim that vim doesn't need to be a C compiler to complete C - that's like comparing cats and potatoes. C and C++ have inheirant type information directly in the code itself. Header files are included verbatim, and easy to parse (when needed). Also, with regards to C, all completable symbols are top-level and require no extra scoping. Let's take a look a python. Tell me how you would gather the information from the sys module in order to complete it. Sure you could run through all of sys.path oh wait! no... somehow you'd have to determine the path python WOULD use to find the module, find the .py file (assuming you don't have a gimped install containing only pyc files), and parse that. Sure it's possible, and sure, it might be easy for sys - but take a look at pygtk. Tell me how long that would take to parse. Now, go to a terminal, type python and hit enter. Then type import sys; dir(sys) - tell me which was: a) faster b) easier c) less error prone d) guaranteed to work on all python installs It would be nice if I could access the spelling/underlining stuff to provide syntax error information. I haven't look too hard yet to see if this is possible, but I for one would find it useful. P.S. Is that really your mail address? Looks bogus to me. But then if it were, you shouldn't stay long on the mailing list... Yes, it is indeed my email address, though I have a few aliases that are a bit more formal. I am quite the trouble maker. I'm sure you can imagine that my address does not validate on many websites, apparently .info domains aren't valid in most peoples eyes. --mark -- sic transit gloria et adulescentia blog | http://blog.hasno.info/blog wiki | http://wiki.hasno.info
