RE: [BUG] Being provided some equal recursive structures, equality operator never stops comparison
ZyX wrote:
Attached script, being sourced causes vim to hang up forever.
Test command:
vim -u NONE -c 'so bug.vim'
To clarify the problem, start Vim 7.3.3 and enter the following
(this is the essence of the script mentioned above, and will
cause Vim to hang, so close all files first):
:let l=[]
:call add(l, l)
:let dict4={l: l}
:call add(dict4.l, dict4)
:echo (dict4 ==# deepcopy(dict4))
The last line causes Vim to hang (CPU goes to 100%, memory is
not consumed).
Starting an investigation:
:let l=[]
:call add(l, l)
:echo 'l=' l
:let k=[]
:call add(k, deepcopy(k))
:echo 'k=' k
The above displays:
l= [[...]]
k= [[]]
I do not know what the ... means but it is probably a bad
sign. Further investigation confirms this:
:redir @a
:let exp = 'l'
:for i in range(1, 10)
: execute 'let val = ' . exp
: echo exp '=' val
: unlet val
: let exp .= '[0]'
:endfor
:redir END
:$put a
---Output---
l = [[...]]
l[0] = [[...]]
l[0][0] = [[...]]
l[0][0][0] = [[...]]
l[0][0][0][0] = [[...]]
l[0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0][0][0][0] = [[...]]
Also, the output from:
:echo string(l)
is
E724: variable nested too deep for displaying
John
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: NetBeans protocol - is support possible under other GUIs?
On Sun, Aug 22, 2010 at 4:19 PM, Tony Mechelynck wrote: I see in various places in this patch (in the + lines) ... defined(FEAT_GUI_X11) || defined(FEAT_GUI_GTK) ... ... !defined(FEAT_GUI_X11) !defined(FEAT_GUI_GTK) ... Isn't the GTK2 GUI an X11 GUI? I mean, is it possible to have FEAT_GUI_GTK true and FEAT_GUI_X11 false? If, as I think, it isn't, then those #if clauses can be simplified. When FEAT_GUI_GTK is defined, then FEAT_GUI_X11 is not defined. FEAT_GUI_X11 could be called more appropriately FEAT_GUI_XT, see http://en.wikipedia.org/wiki/Xlib. Xavier -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
bug: Bold face of Chinese font doesn't work when 'guifontwide' has been specified on win32.
Hi, list, This bug is for Chinese fonts only, English fonts works fine. If I've specified the 'guifontwide', then bold face of chinese fonts doesn't work, they are showed just in normal face. If I've specified the 'guifontwide' with set guifont=Fixedsys:h12:cDEFAULT,Courier_New:h10:cDEFAULT,Terminal:h10:cDEFAULT and leave the 'guifontwide' empty, bold face still doesnt' work. If I've specified the 'guifontwide' with set guifont=Courier_New:h10:cDEFAULT,Fixedsys:h12:cDEFAULT,Terminal:h10:cDEFAULT empty 'guifontwide' will make bold face of Chinese fonts work. My OS: windows 2000 sp4. My vim version: VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 15 2010 15:14:24) MS-Windows 32-bit GUI version with OLE support Compiled by b...@kibaale 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 +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding -footer +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang -mzscheme +netbeans_intg +ole -osfiletype +path_extra +perl/dyn +persistent_undo -postscript +printer -profile +python/dyn +python3/dyn +quickfix +reltime +rightleft +ruby/dyn +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white +tcl/dyn -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 -I. -Iproto -DHAVE_PATHDEF -DWIN32 -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_XPM_W32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 /Fo.\ObjGOLY HTR/ /Ox /GL -DNDEBUG /Zl /MT -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_W32 -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL -DDYNAMIC_TCL_DLL=\tcl83.d ll\ -DDYNAMIC_TCL_VER=\8.3\ -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\python27.dll\ -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\python31.dll\ -D FEAT_PERL -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\perl512.dll\ -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=191 -DDYNAMIC_RUBY_DLL=\msvcrt-ruby191.dll\ -DFEAT_BIG /Fd.\ObjGOL YHTR/ /Zi Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib comdlg32.lib ole32.lib uuid.lib /machine:i386 /no defaultlib gdi32.lib version.lib winspool.lib comctl32.lib advapi32.lib shell32.lib /machine:i386 /nodefaultlib libcmt.lib oleaut32.lib user32.lib /nodefaultlib:pyth on27.lib /nodefaultlib:python31.lib e:\tcl\lib\tclstub83.lib WSock32.lib e:\xpm\lib\libXpm.lib /PDB:gvim.pdb -debug -- Regards, Yue Wu Key Laboratory of Modern Chinese Medicines Department of Traditional Chinese Medicine China Pharmaceutical University No.24, Tongjia Xiang Street, Nanjing 210009, China -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [BUG] Being provided some equal recursive structures, equality operator never stops comparison
Ответ на сообщение «RE: [BUG] Being provided some equal recursive structures,
equality operator never stops comparison»,
присланное в 12:49:15 23 августа 2010, Понедельник,
отправитель John Beckett:
The above displays:
l= [[...]]
k= [[]]
I do not know what the ... means but it is probably a bad
If I am not mistaking, ... means ``I already displayed this structure, so I do
not want to display it for the second time''. Example:
:let d={}
:let l=[d, d]
:echo l
[{}, {...}]
This makes possible echoing recursive data structures, like the one that causes
Vim to hang up. Function string() refuses to compose this structures as it is
not possible to do in a single eval statement.
Текст сообщения:
ZyX wrote:
Attached script, being sourced causes vim to hang up forever.
Test command:
vim -u NONE -c 'so bug.vim'
To clarify the problem, start Vim 7.3.3 and enter the following
(this is the essence of the script mentioned above, and will
cause Vim to hang, so close all files first):
:let l=[]
:call add(l, l)
:let dict4={l: l}
:call add(dict4.l, dict4)
:echo (dict4 ==# deepcopy(dict4))
The last line causes Vim to hang (CPU goes to 100%, memory is
not consumed).
Starting an investigation:
:let l=[]
:call add(l, l)
:echo 'l=' l
:let k=[]
:call add(k, deepcopy(k))
:echo 'k=' k
The above displays:
l= [[...]]
k= [[]]
I do not know what the ... means but it is probably a bad
sign. Further investigation confirms this:
:redir @a
:let exp = 'l'
:for i in range(1, 10)
:
: execute 'let val = ' . exp
: echo exp '=' val
: unlet val
: let exp .= '[0]'
:
:endfor
:redir END
:$put a
---Output---
l = [[...]]
l[0] = [[...]]
l[0][0] = [[...]]
l[0][0][0] = [[...]]
l[0][0][0][0] = [[...]]
l[0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0][0][0] = [[...]]
l[0][0][0][0][0][0][0][0][0] = [[...]]
Also, the output from:
:echo string(l)
is
E724: variable nested too deep for displaying
John
signature.asc
Description: This is a digitally signed message part.
[PATCH] link.sh: do not reduce library if linker supports --as-needed
link.sh tries to avoid overlinking in a hackish way. At least GNU ld supports --as-needed which provides the same functionality at linker level. Let's use it. Signed-off-by: Kirill A. Shutemov kir...@shutemov.name --- src/Makefile |2 +- src/config.mk.in |1 + src/configure.in | 17 + src/link.sh |6 +- 4 files changed, 24 insertions(+), 2 deletions(-) diff --git a/src/Makefile b/src/Makefile index 5c0729f..0156084 100644 --- a/src/Makefile +++ b/src/Makefile @@ -1688,7 +1688,7 @@ $(VIMTARGET): auto/config.mk objects $(OBJ) version.c version.h $(CCC) version.c -o objects/version.o @LINK=$(PURIFY) $(SHRPENV) $(CClink) $(ALL_LIB_DIRS) $(LDFLAGS) \ -o $(VIMTARGET) $(OBJ) objects/version.o $(ALL_LIBS) \ - MAKE=$(MAKE) sh $(srcdir)/link.sh + MAKE=$(MAKE) NO_LINK_SH=$(NO_LINK_SH) sh $(srcdir)/link.sh xxd/xxd$(EXEEXT): xxd/xxd.c cd xxd; CC=$(CC) CFLAGS=$(CPPFLAGS) $(CFLAGS) \ diff --git a/src/config.mk.in b/src/config.mk.in index 7154114..cd334c6 100644 --- a/src/config.mk.in +++ b/src/config.mk.in @@ -30,6 +30,7 @@ TAGPRG= @TAGPRG@ CPP= @CPP@ CPP_MM = @CPP_MM@ DEPEND_CFLAGS_FILTER = @DEPEND_CFLAGS_FILTER@ +NO_LINK_SH = @NO_LINK_SH@ X_CFLAGS = @X_CFLAGS@ X_LIBS_DIR = @X_LIBS@ X_PRE_LIBS = @X_PRE_LIBS@ diff --git a/src/configure.in b/src/configure.in index 3b9f812..a4e5e74 100644 --- a/src/configure.in +++ b/src/configure.in @@ -3479,6 +3479,23 @@ else fi AC_SUBST(DEPEND_CFLAGS_FILTER) +dnl link.sh tries to avoid overlinking in a hackish way. +dnl At least GNU ld supports --as-needed which provides the same functionality +dnl at linker level. Let's use it. +AC_MSG_CHECKING(linker --as-needed support) +NO_LINK_SH= +# Check if linker supports --as-needed and --no-as-needed options +if $CC -Wl,--help 2/dev/null | grep as-needed /dev/null; then + LDFLAGS=$LDFLAGS -Wl,--as-needed + NO_LINK_SH=yes +fi +if test $NO_LINK_SH = yes; then + AC_MSG_RESULT(yes) +else + AC_MSG_RESULT(no) +fi +AC_SUBST(NO_LINK_SH) + dnl write output files AC_OUTPUT(auto/config.mk:config.mk.in) diff --git a/src/link.sh b/src/link.sh index 3d90f3c..06632dc 100755 --- a/src/link.sh +++ b/src/link.sh @@ -16,11 +16,15 @@ echo $LINK link.cmd exit_value=0 +if test $NO_LINK_SH = yes; then + echo link.sh: \$NO_LINK_SH set to 'yes': no needed in reducing library set. + echo auto/link.sed +elif test -f auto/link.sed; then + # # If auto/link.sed already exists, use it. We assume a previous run of # link.sh has found the correct set of libraries. # -if test -f auto/link.sed; then echo link.sh: The file 'auto/link.sed' exists, which is going to be used now. echo link.sh: If linking fails, try deleting the auto/link.sed file. echo link.sh: If this fails too, try creating an empty auto/link.sed file. -- Kirill A. Shutemov -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
string() cannot compose inf and nan values
In the documentation of string() function it is written that ``if {expr} is a
Number, Float, String or a composition of them, then the result can be parsed
back with eval()'' which is not true: special Float values: ``inf'', ``-inf''
and ``nan'' are not parsed back by eval unless there are variables with names
``inf'' and ``nan'' that have appropriate values. I think this should be at
least mentioned in documentation, like I have done in attached patch.
# HG changeset patch
# User ZyX kp-...@yandex.ru
# Date 1282568524 -14400
# Node ID a8029f4ea5a4ca85e7a7a21f13c288ff9ea8a27b
# Parent 073ff46fe397220b4c3946a8f4b349e8d8578a65
Added note about string() nan and inf handling
diff -r 073ff46fe397 -r a8029f4ea5a4 runtime/doc/eval.txt
--- a/runtime/doc/eval.txt Fri Aug 20 11:11:57 2010 +0200
+++ b/runtime/doc/eval.txt Mon Aug 23 17:02:04 2010 +0400
@@ -5442,6 +5442,9 @@
List[item, item]
Dictionary {key: value, key: value}
Note that in String values the ' character is doubled.
+ You should also remember that special Float values like inf
+ (infinity) and nan (not a number) are considered to be
+ variable names and so cannot be parsed back.
Also see |strtrans()|.
*strlen()*
signature.asc
Description: This is a digitally signed message part.
Re: [BUG] Being provided some equal recursive structures, equality operator never stops comparison
If I am not mistaking, ... means ``I already displayed this structure, so I do
not want to display it for the second time''. Example:
:let d={}
:let l=[d, d]
:echo l
[{}, {...}]
This makes possible echoing recursive data structures, like the one that
causes
In such a case, it would be better to use a flattened representation
of cyclic data.
For example, if you would excuse my Lisp,
(define x (cons 'foo 'bar)) ;; create a pair
(set-cdr! x x) ;; let the second element be the pair itself
(print x) ;; gives #1=(foo . #1#)
The good thing is that you can even read it back!
P!
--
Français, English, 日本語, 한국어
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: [bug] cursorcolumn not highlighted beyond end of line with 'set rightleft'
On 21/08/10 07:10, Dominique Pellé wrote: Hi I notice that the cursorcolumn is not highlighted beyond the end of the lines when using 'set rightleft'. Also, cursorcolumn is highlighted in the wrong column in folds: Steps to reproduce: $ cd vim/src $ vim -u NONE -c 'set cuc rl fdm=marker' \ -c 'hi CursorColumn ctermbg=red' -c 'norm 3l' fold.c The same kind of bug happens also with 'colorcolumn': $ vim -u NONE -c 'set cc=10 rl fdm=marker' fold.c See screenshots at: http://dominique.pelle.free.fr/pic/vim-cuc-rightleft.png http://dominique.pelle.free.fr/pic/vim-cc=10-rightleft.png -- Dominique I can reproduce this lack of highlight beyond EOL, and I see some other weird effects: - When 'rightleft' is set, the blinking cursor is not where it should be. If I click the mouse, the crosshair highlights (CursorLine and CursorColumn) intersect where I clicked, and that's the character I get with ga, but the blinking cursor is at the horizontally symmetrical position. However I see this when setting 'rl' in help.txt but not in Session.vim. Not sure what triggers it: Tried to reproduce it by setting 'ma' and 'buftype=help' but couldn't. (I know it makes no sense to display the English help in RTL mode but that's the file which was open when I tested.) - When I hit Left or Right in 'rightleft' mode, the crosshairs go right (to the previous character) in both cases. OTOH, h moves them left (to the next character) while l moves them right (to the previous character). Best regards, Tony. -- Insanity is hereditary. You get it from your kids. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: 7.3 unable to load ruby 1.9.2?
I haven't had a chance to look at if_ruby.c starting herehttp://code.google.com/p/vim/source/browse/src/if_ruby.c#412 Who maintains if_ruby.c and how do we get that person feedback? From a brief look, I'll bet the root of this issue that http://code.google.com/p/vim/source/browse/src/if_ruby.c#310 contains pointers to functions no longer exported by the ruby dll and http://code.google.com/p/vim/source/browse/src/if_ruby.c#429 unloads the ruby dll thereby making it look like the dll was never found. Also, updating if_ruby.c to abstract the dll loading api as done in http://code.google.com/p/vim/source/browse/src/if_lua.c#45 would be a good thing. Jon -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: 7.3 unable to load ruby 1.9.2?
I've got a patch that's working for me on Win7 32-bit using Ruby 1.9.2 from the MinGW 4.5.0 built http://rubyinstaller.org/ After a bit more testing I'll post it for your consideration. Jon -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
[patch] fixed 3 bugs found with smatch static analyzer
Hi
I tried the static analyzer smatch (http://smatch.sourceforge.net/) with
Vim-7.3.3. It gives quite some noise but the following 3 defects look like
real bugs:
spell.c +7238 spell_read_wordfile(118) error: strcpy() '(line)' too
large for '(spin-si_region_name)' (17 vs 16)
spell.c +9548 init_spellfile(45) warn: add some parenthesis here?
syntax.c +7611 do_highlight(823) error: buffer overflow 'buf' 100 = 100
Fixed in attached patch.
-- Dominique
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
diff -r 073ff46fe397 src/spell.c
--- a/src/spell.c Fri Aug 20 11:11:57 2010 +0200
+++ b/src/spell.c Mon Aug 23 21:05:22 2010 +0200
@@ -7229,7 +7229,7 @@
else
{
line += 8;
- if (STRLEN(line) 16)
+ if (STRLEN(line) = 16)
smsg((char_u *)_(Too many regions in %s line %d: %s),
fname, lnum, line);
else
@@ -9545,7 +9545,7 @@
/* Create the spell directory if it doesn't exist yet. */
l = (int)STRLEN(buf);
vim_snprintf((char *)buf + l, MAXPATHL - l, /spell);
- if (!filewritable(buf) != 2)
+ if (filewritable(buf) != 2)
vim_mkdir(buf, 0755);
l = (int)STRLEN(buf);
diff -r 073ff46fe397 src/syntax.c
--- a/src/syntax.c Fri Aug 20 11:11:57 2010 +0200
+++ b/src/syntax.c Mon Aug 23 21:05:22 2010 +0200
@@ -7600,7 +7600,7 @@
/*
* Copy characters from arg[] to buf[], translating codes.
*/
- for (p = arg, off = 0; off 100 *p; )
+ for (p = arg, off = 0; off 99 *p; )
{
len = trans_special(p, buf + off, FALSE);
if (len) /* recognized special char */
Re: 7.3 unable to load ruby 1.9.2?
Leonardo Valeri Manera schrob am 22.08.2010 16:39: Something very similar happens when compiling 7.3.003 against 1.9.2 using MSVC10/MSSDK-7.1 - the static build obviously fails with a slightly different if_ruby.obj: error LNK2001: unresolved external symbol __imp__ruby_errinfo For me, it already breaks in if_ruby.c. VS2010, Win7 32-bit. GTK that it's not me. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: [BUG] Being provided some equal recursive structures, equality operator never stops comparison
Ответ на сообщение «Re: [BUG] Being provided some equal recursive structures,
equality operator never stops comparison»,
присланное в 17:34:55 23 августа 2010, Понедельник,
отправитель Adrien Axioplase Piérard:
But in vim, you cannot use assignment in eval statemnts. You possibly can
provide a workaround (as an edge case: you can dump varible into string using
my
yaml.vim plugin and then load it: YAML is capable of representing recursive
data
and my plugin is capable of loading it), but I do not know how to do this using
only built-in functions.
Текст сообщения:
If I am not mistaking, ... means ``I already displayed this structure, so
I do not want to display it for the second time''. Example:
:let d={}
:let l=[d, d]
:echo l
[{}, {...}]
This makes possible echoing recursive data structures, like the one that
causes
In such a case, it would be better to use a flattened representation
of cyclic data.
For example, if you would excuse my Lisp,
(define x (cons 'foo 'bar)) ;; create a pair
(set-cdr! x x) ;; let the second element be the pair itself
(print x) ;; gives #1=(foo . #1#)
The good thing is that you can even read it back!
P!
signature.asc
Description: This is a digitally signed message part.
Re: [BUG] Being provided some equal recursive structures, equality operator never stops comparison
On Mon, Aug 23, 2010 at 4:45 PM, ZyX wrote:
Ответ на сообщение «Re: [BUG] Being provided some equal recursive structures,
equality operator never stops comparison»,
присланное в 17:34:55 23 августа 2010, Понедельник,
отправитель Adrien Axioplase Piérard:
But in vim, you cannot use assignment in eval statemnts.
You almost can. You can if you don't mind setting them local to a
particular buffer or window, at least.
:echo eval(setbufvar(bufnr(''), 'x', 42))
0
:echo b:x
42
~Matt
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: 7.3 unable to load ruby 1.9.2?
I've tested the following patch for download [1] works so far with the Ruby for Windows 1.8.7p302, 1.9.1p430, and 1.9.2p0 from http://rubyinstaller.org on a Win7 Ultimate 32-bit system using MSys/MinGW/TDM 4.5.0 or LLVM- GCC 2.7. I haven't tested on my Ubuntu system and it's unlikely I find the time to do so. The problem was the 'rb_str2cstr' api first deprecated in Ruby 1.7.1 and finally removed in 1.9.2p0. The fix was do ifdef in the replacement 'rb_string_value' api which was first available in Ruby 1.7.1. Additionally, I injected the same cross-platform dll/so loading code used in the if_lua.c and if_python.c code. This *should* work on Ruby 1.6+. Please review, test, and let me know what further mods are needed. Jon [1] http://gist.github.com/546039 -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: 7.3 unable to load ruby 1.9.2?
Jon schrob am 24.08.2010 02:27: Please review, test, and let me know what further mods are needed. :s I am currently trying to get my Ruby installation working again. It "can't find inttypes.h" although I defined HAVE_INTTYPES_H as 0. Despairing. (I know I had it working with Ruby 1.9.1, damn.) -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: 7.3 unable to load ruby 1.9.2?
On 24 August 2010 02:44, tux. der_tux...@arcor.de wrote: Jon schrob am 24.08.2010 02:27: Please review, test, and let me know what further mods are needed. :s I am currently trying to get my Ruby installation working again. It can't find inttypes.h although I defined HAVE_INTTYPES_H as 0. Despairing. (I know I had it working with Ruby 1.9.1, damn.) Make sure you're not crossing the headers - if you're compiling with mingw you must point it @ i386-mingw32 ruby headers, otherwise is at i386-mswin32. So long as its a dynamic build of vim, all that matters is that you have the right includes /for the compiler you're building vim with/, so you can use mswin32 includes to link to mingw ruby and vice-versa. Just steal the includes you don't have (the whole arch folder) and just put in with the other. Cheers, Leo -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: 7.3 unable to load ruby 1.9.2?
Leonardo Valeri Manera schrob am 24.08.2010 02:54:
Make sure you're not crossing the headers - if you're compiling with
mingw you must point it @ i386-mingw32 ruby headers, otherwise is at
i386-mswin32.
A, one fine day I'll set up my printer and print this on a very,
very huge sheet of paper... :-/
Got it, thanks once more ...
With the matching mswin32 build, all is fine (again). Whew...
Bookmarked it now to avoid any further confusion on my side, like
when Ruby 1.9.3 comes out ...
Anyway: Jon's patch seems to work for me.
After applying it, :ruby puts("Hello") echoes "Hello" correctly. :-)
(with DYNAMIC_RUBY)
Regards.
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: [BUG] Diacriticals does not match inside collection while searching buffer
On Tue, 24 Aug 2010, ZyX wrote:
The following code should echo the same result, but it does not unless
file contains no combining acute accents.
:echo search('\%u0301') will echo number of line with acute accent
:echo search('[\u0301]') will always echo 0
The following works just fine (both echoes 0):
:echo match(\u0301, '\%u0301')
:echo match(\u0301, '[\u0301]')
Tested both on vim-7.3 from gentoo repos and vim-7.3/2577:073ff46fe397.
Note, though, that this also echoes 0:
:echo match(e\u0301, '\%u0301')
And this echoes -1:
:echo match(e\u0301, '[\u0301]')
It seems to me one or the other of \%u or [\u] is being 'smart'
about combining characters, and my guess is that [\u0301] only matches
at the beginning of a string because the combining acute has nothing
which with to combine.
--
Best,
Ben
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
menu.vim bug
Hi, There is floating bug that I can see when I start gvim (7.3, winxp, binaries from vim.org): http://picasaweb.google.com/lh/photo/pEQo_1GDSrWgLMn9BWk_MA?feat=directlink It just happens once in a while so I can not find steps to reproduce it. Maxim. -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
