Re: exists(*Foo!garbage) = 1 ?
Hi Bram,
On 4/29/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
This happens not just for functions, but variables etc. also. For
variables, I can work around this by using has_key(g:, varname)
instead of exists('g:'.varname).
Right, extra text after the function name was ignored. It's easy to
change, see the patch below.
Thanks for the patch.
Would there be scripts that depended on the text being ignored? Hmm, if
someone has been using exists('function()') then that worked, but won't
work after the patch.
I think I better not change this just before a release.
I would think that a major release of vim is a good time to fix such
things which are possibly not backwards compatible, since most users are
expecting significant changes anyways. Also I never saw that you could
use exists('function()') anywhere in the docs (it always returns 0 when
I try). Its supposed to be exists('*function'), right? Why accomodate
undocumented behavior, when there is a good documented alternative?
I am afraid that if this gets into vim7 release, then this behavior will
be promoted to a feature...
Thanks,
Srinath
Re: Install Fails on Windows
On Sat 29-Apr-06 3:49pm -0600, Bram Moolenaar wrote: There are two setups, the Unix one and the MS-Windows one. If you use the Unix setup you need to do make install. Thus uses the files in the ../runtime directory that were unpacked from the Unix tar archive. If you use the MS-Windows setup you should unpack the vim70xxrt.zip file, which puts the runtime files below the src directory, without a runtime directory. Then you can use the install.exe. The problem with this is that there is only one current beta and that is the the unix form of the Vim tree. Even if I copy my executables to runtime\, install complains with: [c:\vim\vim70f\runtime]install This program sets up the installation of Vim 7.0f BETA ERROR: Install program not in directory vim70f This program can only work when it is located in its original directory The solutions provided by Suresh Govindachar and Georg Dahn both appear to work, but involve copying the contents of runtime\ on top of vim70.f\ (which should produce some pretty ugly results when CVS is back again :-) I was hoping there was a simple way of enabling dosinst.c to work with the unix tree. Since Alpha and Beta versions have worked just fine without installing, and there are no patches to apply to the older vim7 files that are are available, I'll just not install until the release and subsequent patch releases. Thanks to Suresh, Georg and you for your comments. -- Best regards, Bill
vim70f, ft=vim, syn on -- highlighting of matching parens fails
Hello Vim-Dev,
I was browsing some Vim-scripts and I found strange that a highlighting
of matching parens fails on this line:
let l:fg=substitute(l:bcdefg,.*\\C . l:cde . ,\\([^,]\\),.*,\\1,)
It fails when the cursor is on
- the first, the second of '('
- the first '['
- the last ')'
- everything else is OK.
It works well when ':syn off', it fails when ':syn on'. ft=vim.
I can reproduce the problem with this simple line alone in a file.vim or
by changing the 'ft' and 'syn' for a buffer.
Best regards,
Milan
--
* Milan Berta
* Institute of Physics
* Academy of Sciences of the Czech Republic
* Na Slovance 2
* CZ-182 21 Prague 8
* Czech Republic
*
* mailto: [EMAIL PROTECTED]
* phone: +420 266 052 650, +420 266 052 748
* fax:+420 286 890 416
* URL:http://www.fzu.cz/
VIM - Vi IMproved 7.0f BETA (2006 Apr 24, compiled Apr 25 2006 00:22:48)
Compiled by [EMAIL PROTECTED]
Huge 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 +cursorshape +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 -mzscheme
-netbeans_intg -osfiletype +path_extra -perl +postscript +printer +profile
-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_interact
+xterm_clipboard -xterm_save
system vimrc file: $VIM/vimrc
user vimrc file: $HOME/.vimrc
user exrc file: $HOME/.exrc
fall-back for $VIM: /home/bertm0am/local/share/vim
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce
-Wall -I/usr/X11R6/include
Linking:
gcc -L/usr/X11R6/lib -L/usr/local/lib -o vim-lXt -lncurses -lacl
Re: exists(*Foo!garbage) = 1 ?
Srinath Avadhanula wrote:
On 4/29/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
This happens not just for functions, but variables etc. also. For
variables, I can work around this by using has_key(g:, varname)
instead of exists('g:'.varname).
Right, extra text after the function name was ignored. It's easy to
change, see the patch below.
Thanks for the patch.
Would there be scripts that depended on the text being ignored? Hmm, if
someone has been using exists('function()') then that worked, but won't
work after the patch.
I think I better not change this just before a release.
I would think that a major release of vim is a good time to fix such
things which are possibly not backwards compatible, since most users are
expecting significant changes anyways. Also I never saw that you could
use exists('function()') anywhere in the docs (it always returns 0 when
I try). Its supposed to be exists('*function'), right? Why accomodate
undocumented behavior, when there is a good documented alternative?
I am afraid that if this gets into vim7 release, then this behavior will
be promoted to a feature...
The problem of changing something like this is that all scripts that are
included in the release need to be checked for effects. And there are
lots of scripts now. I wouldn't be surprised if, for example, the netrw
plugin stops working properly.
--
ARTHUR: CHARGE!
[The mighty ARMY charges. Thundering noise of feet. Clatter of coconuts.
Shouts etc. Suddenly there is a wail of a siren and a couple of police
cars roar round in front of the charging ARMY and the POLICE leap out and
stop them. TWO POLICEMAN and the HISTORIAN'S WIFE. Black Marias skid up
behind them.]
HISTORIAN'S WIFE: They're the ones, I'm sure.
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: How long does it take for svn to sync with whereever it is the real sources are?
Hisashi T Fujinaka was just wondering, since every time Bram announces a new release (7.0g this time) [he gets] itchy. :) A day or so ago, Edward L. Fox wrote on vim@vim.org: | Hi, I'm the subversion repository maintainer. I sync the | subversion repository with the CVS repository everyday at | about 9:00 (+0800), or 1:00 (GMT). So if you checkout the code | at about 2:00 (GMT), you can get the latest version. :-) --Suresh
completeopt: menu|menuone + longest = bug?
Tested with vim70g Given the following file contents: BlahBlahImpl BlahBlah.Type If I try to perform the following on a new line at the end of the file Blc-xc-n or p.Tc-n or p The resulting text should be BlahBlah.Type However, if my 'completeopt' has menu and longest, or menuone and longest, I get unexpected results. Case 1: Blc-xc-n.Tc-n Results in: BlahBlah.T Vim Message = Back at original Subsiquent c-n calls have no effect. Case 2: Blc-xc-p.Tc-p Results in: Bl Vim Message = Back at original Subsiquent c-p calls have no effect. This case is even worse than the first since my previously completed BlahBlah text is now gone. Note: I tested the above by simply starting vim as follows: To show unexpected behavior: vi -u NONE -c set completeopt=menu,longest To show expected behavior: vi -u NONE -c set completeopt=longest or vi -u NONE -c set completeopt=menu -- eric
