I know it's late to vote, but some sort of sane 'gdb' integration would be
supremely useful. I haven't found any packages for this that don't involve a
lot of setup.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying t
On Tue, May 21, 2013 at 10:04 AM, Shannon Bay wrote:
> After installing YouCompleteMe I found that opening java files caused an
> deadly signal ABRT.
>
> See backtrace and futher details on
> https://github.com/valloric/youcompleteme/issues/332
Patch 973 causes ABRT and is fixed in patch 975, i
On Tue, May 21, 2013 at 7:13 AM, Cesar Romani wrote:
> By updating from 7.3.969 to 7.3.981 the following command doesn't work
> anymore:
> %s/""/\='"'.matchstr(getline("."), '\d\+\ze<').'"'
>
> Let's say I use this command on the following text:
> Table of Contents 5
> Acknowledgements 7
> Preface
вторник, 21 мая 2013 г., 5:36:45 UTC+4 пользователь MarcWeber написал:
> Yet another suggestion - what about adding &rtp to sys.path somehow ?
> (with or without python version site-packages or the like)
>
> Then you could
> - write .py files
> - use them from python by
>
> import module
>
Hi,
2013/05/21 Tue 9:16:55 UTC+9 mattn wrote:
> * Some plugins doesn't work
> * \%u is disabled
> * test64 contains tests for multi-byte
> * test95 doesn't pass without enc=utf-8
* Strange condition in the line 1094:
if (*regparse == 'n' || *regparse == 'n')
\%u seems to be disabled because of
oh and it would be cool if python/*.py files could be loaded then, too ?
Did I also miss such feature proposal?
Marc Weber
--
--
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
Yet another suggestion - what about adding &rtp to sys.path somehow ?
(with or without python version site-packages or the like)
Then you could
- write .py files
- use them from python by
import module
do_stuff()
Yes - it can be trivially implemented in tools like vim-addon-manager,
but
1) That the new regex *silently* fails if something is not supported is
no option - you should throw an error IMHO so that people know that
something goes wrong.
2) https://gist.github.com/MarcWeber/5616733
I've created an unfinished QuickCheck script to compare the old and the
new engine - ho
* Some plugins doesn't work
* \%u is disabled
* test64 contains tests for multi-byte
* test95 doesn't pass without enc=utf-8
Here is japanese discusstion
https://github.com/vim-jp/issues/issues/390#issuecomment-18181263
Thanks.
--
--
You received this message from the "vim_dev" maillist.
Do no
Excerpts from ZyX's message of Mon May 20 17:04:25 +0200 2013:
> Python is not VimL: proposed API is not good for python; and I have already
> written
Well - I just thought it would be a nice improvement for VimL, because
it will never happen that all plugins get rewritten using python.
So we need
By updating from 7.3.969 to 7.3.981 the following command doesn't work
anymore:
%s/""/\='"'.matchstr(getline("."), '\d\+\ze<').'"'
Let's say I use this command on the following text:
Table of Contents 5
Acknowledgements 7
Preface 9
Introduction to the Second, Revised Edition
11
Introduction 13
Sorry, It'ts not class name. it's property.
\p{Katakana}
On Tuesday, May 21, 2013 8:18:23 AM UTC+9, mattn wrote:
> Thanks. BTW) I was thinking that vim's regexp engine can't handle CJK
>
> class names like [[::katakana::]] and it's nessecary for CJK people.
>
> Some regexp engine support CJK cl
On Mon, May 20, 2013 at 04:15:46PM -0700, Ben Fritz wrote:
> On Monday, May 20, 2013 5:52:39 PM UTC-5, toothpik wrote:
> > - Forwarded message from tooth pik -
> >
> >
> >
> > Date: Mon, 20 May 2013 17:44:28 -0500
> >
> > From: tooth pik
> >
> > To: vim_dev@googlegroups.com
> >
> >
- Forwarded message from tooth pik -
Date: Mon, 20 May 2013 17:52:39 -0500
From: tooth pik
To: vim_dev@googlegroups.com
Subject: [toothp...@gmail.com: deadly signal gone with 7.3.980 but new issue]
- Forwarded message from tooth pik -
Date: Mon, 20 May 2013 17:44:28 -0500
From
Thanks. BTW) I was thinking that vim's regexp engine can't handle CJK
class names like [[::katakana::]] and it's nessecary for CJK people.
Some regexp engine support CJK class names.
How about to add this?
On 5/21/13, Ken Takata wrote:
> Hi,
>
> 2013/05/20 Mon 23:39:13 UTC+9 mattn wrote:
>> On Mo
On Monday, May 20, 2013 5:52:39 PM UTC-5, toothpik wrote:
> - Forwarded message from tooth pik -
>
>
>
> Date: Mon, 20 May 2013 17:44:28 -0500
>
> From: tooth pik
>
> To: vim_dev@googlegroups.com
>
> Subject: deadly signal gone with 7.3.980 but new issue
>
>
>
> with an interesti
- Forwarded message from tooth pik -
Date: Mon, 20 May 2013 17:44:28 -0500
From: tooth pik
To: vim_dev@googlegroups.com
Subject: deadly signal gone with 7.3.980 but new issue
with an interesting trip down {whack vim\; re-clone vim}-lane (Tony's
method of ignoring tags got me in git trou
with an interesting trip down {whack vim\; re-clone vim}-lane (Tony's
method of ignoring tags got me in git trouble I didn't know how to get
out of) I can now open index.html without the deadly ABRT but now
inside an edit session of that module scrolling is severely impeded
the repeat rate on my k
Patch 7.3.981
Problem:In the old regexp engine \i, \I, \f and \F don't work on
multi-byte characters.
Solution: Dereference pointer properly.
Files: src/regexp.c, src/testdir/test64.in, src/testdir/test64.ok
*** ../vim-7.3.980/src/regexp.c 2013-05-20 21:49:08.0 +02
On Mon, May 20, 2013 at 09:49:27AM -0700, Ben Fritz wrote:
> On Monday, May 20, 2013 5:17:54 AM UTC-5, toothpik wrote:
> > I don't know much yet except a huge python (2.7) enabled vim 7.3.793 is
> >
> > getting bombed with a deadly signal ABRT when I try to edit my
> >
> > index.html module
> >
Patch 7.3.980
Problem:Regexp logs may contain garbage. Character classes don't work
correctly for multi-byte characters.
Solution: Check for end of post list. Only use "is" functions for
characters up to 255. (Ken Takata)
Files: src/regexp_nfa.c
*** ../vim-7.3
Ken Takata wrote:
> 2013/05/20 Mon 23:39:13 UTC+9 mattn wrote:
> > On Monday, May 20, 2013 11:38:35 PM UTC+9, mattn wrote:
> > > https://gist.github.com/mattn/5612637
> >
> > Ah, sorry. I had pushed "Post" button.
> > But subtitle says all.
>
> I also found some problems in regexp_nfa:
>
> 1.
Yasuhiro Matsumoto wrote:
> https://gist.github.com/mattn/5612637
Thanks. There are more allocation and size problems...
--
ARTHUR: If you do not open these doors, we will take this castle by force ...
[A bucket of slops land on ARTHUR. He tries to retain his dignity.]
"M
Patch 7.3.979
Problem:Complex NFA regexp doesn't work.
Solution: Set actual state stack end instead of using an arbitrary number.
(Yasuhiro Matsumoto)
Files: src/regexp_nfa.c
*** ../vim-7.3.978/src/regexp_nfa.c 2013-05-20 21:49:08.0 +0200
--- src/regexp_nfa.c
Taro Muraoka wrote:
> Name of regexp debug log files are very general.
>
> NFA Engine: list.log
> BT Engine: debug.log
>
> I change those as self describing, like this:
>
> NFA Engine: list.log -> nfa_regexp_debug.log
> BT Engine: debug.log -> bt_regexp_debug.log
>
> Please check atta
Xavier de Gaye wrote:
> On Fri, May 17, 2013 at 9:22 PM, Bram Moolenaar wrote:
> >
> > ZyX wrote:
> >
> >> > Interesting. So we would have a $VIMRUNTIME/python directory and we can
> >> > put Python scripts there that we include with the distribution.
> >> >
> >> > I'm sure it is only a small st
Patch 7.3.978
Problem:Regexp debug logs don't have a good name.
Solution: Use clear names and make it possible to write logs for the old and
new engines separately. (Taro Muraoka)
Files: src/regexp.c, src/regexp_nfa.c
*** ../vim-7.3.977/src/regexp.c 2013-05-19 19:16:25.000
Taro Muraoka wrote:
> > So, how about add some documentation for EUC-JP users in
> > src/po/README.txt, instead of including ja.euc-jp.po. I'll write it.
>
> I wrote a section for it.
> Please look in an attached patch.
Thanks. I added a bit more text for those who don't know how this
works:
Patch 7.3.977
Problem:Compiler warnings on 64 bit Windows.
Solution: Add type casts. (Mike Williams) Also fix some white space and
uncomment what was commented-out for testing.
Files: src/regexp_nfa.c
*** ../vim-7.3.976/src/regexp_nfa.c 2013-05-20 13:55:17.0 +
Ein Brown wrote:
> Hi, I seem to have run into a bug with mappings run inside "(insert)
> Visual" mode.
>
> example here:
> http://stackoverflow.com/a/16230661/1176650
So this is about:
vnoremap ugv
You must understand that this is written to be executed in Visual mode.
So Vim does CTRL-G, t
Hi, I seem to have run into a bug with mappings run inside "(insert) Visual"
mode.
example here:
http://stackoverflow.com/a/16230661/1176650
--
--
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, v
On Mon, 20 May 2013, Bram Moolenaar wrote:
Patch 7.3.974
Problem:Can't build with ruby 1.8.5.
Solution: Only use ruby_init_stack() when RUBY_INIT_STACK is defined.
(Yukihiro Nakadaira)
Files: src/if_ruby.c
This patch does allow me to build Vim with Ruby on CentOS 5.9 aga
On Monday, May 20, 2013 5:17:54 AM UTC-5, toothpik wrote:
> I don't know much yet except a huge python (2.7) enabled vim 7.3.793 is
>
> getting bombed with a deadly signal ABRT when I try to edit my
>
> index.html module
>
>
>
> my first instinct was to disable the runtime/plugin/tohtml.vim, b
Hi,
2013/05/20 Mon 23:39:13 UTC+9 mattn wrote:
> On Monday, May 20, 2013 11:38:35 PM UTC+9, mattn wrote:
> > https://gist.github.com/mattn/5612637
>
> Ah, sorry. I had pushed "Post" button.
> But subtitle says all.
I also found some problems in regexp_nfa:
1. Character classes such as [[:cntrl
> It might be the same crash that happens on:
>
>
>
> :echo search("[^A-z]")
>
>
>
> No fix yet.
i just compiled the new patches and it seems they fixed my problem. at least
now vim doesn't crash as soon as i open a php file. i'll do some editing and
see if it crashes again.
--
--
Added tags interface, vim.environ, signs.find(linenr), suggestion for
__enter__/__exit__:
``vim._tag_files``, ``{buffer}._tag_files``:
Iterators yielding tag file names. ``list(vim._tag_files)`` is an expanded
version of ``&tags`` option.
``vim.tags``, ``{buffer}.tags``:
Mapping-li
> If we are at it: The signs feature is broken by design, because its the
> user setting "sign ids" - so multiple scripts don't know where to start.
>
> What about adding a next_sign_id() function returning a new unused id ?
> A simple counter should be enough. The perfect fix would be dropping t
On Monday, May 20, 2013 11:38:35 PM UTC+9, mattn wrote:
> https://gist.github.com/mattn/5612637
Ah, sorry. I had pushed "Post" button.
But subtitle says all.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For mor
https://gist.github.com/mattn/5612637
--
--
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
---
You received this message because you are subscribed to the
Yeah, it works fine after I did a clean-clean build at home. Probably a
patching problem on my part.
--
--
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
--
On 20/05/13 12:17, tooth pik wrote:
I don't know much yet except a huge python (2.7) enabled vim 7.3.793 is
getting bombed with a deadly signal ABRT when I try to edit my
index.html module
my first instinct was to disable the runtime/plugin/tohtml.vim, but I
still get the deadly signal when I tr
On 20/05/2013 14:20, Mike Williams wrote:
On 20/05/2013 12:37, Bram Moolenaar wrote:
However, there is a check for the pointer not to go beyond the end:
#define EMIT(c) do {\
if (post_ptr >= post_end)\
return FAIL;
On 20/05/2013 12:37, Bram Moolenaar wrote:
Charles Peacech wrote:
On Mon, May 20, 2013 at 5:28 PM, Charles wrote:
Hi,
In my gvim, the new regexp engine crash gvim for this regexp
0x02a60c72 "htmlSpecialChar "&#\=[0-9A-Za-z]\{1,8};""
The crash happens here
/*
* Allocate and initialize n
On 20/05/13 13:44, Bram Moolenaar wrote:
Patch 7.3.975
Problem:Crash in regexp parsing.
Solution: Correctly compute the end of allocated memory.
Files: src/regexp_nfa.c
I had a crash when opening css files (not js or text files) with 're'
set to 0 but this patch fixes it. :-)
Be
Name of regexp debug log files are very general.
NFA Engine: list.log
BT Engine: debug.log
I change those as self describing, like this:
NFA Engine: list.log -> nfa_regexp_debug.log
BT Engine: debug.log -> bt_regexp_debug.log
Please check attached patch.
I also added two flags to contr
Taro Muraoka wrote:
> Thank you for thinking about it.
>
> And we had discussed it in vim-jp (you know, it is Japanese vim users
> and developers community). The discussion was held in Japanese, but I
> reveal its URL for reference.
>
> https://github.com/vim-jp/issues/issues/364
>
>
> > How
> So, how about add some documentation for EUC-JP users in
> src/po/README.txt, instead of including ja.euc-jp.po. I'll write it.
I wrote a section for it.
Please look in an attached patch.
Best.
2013/5/20 MURAOKA Taro :
> Thank you for thinking about it.
>
> And we had discussed it in vim-jp
On Mon, May 20, 2013 at 6:34 PM, Bram Moolenaar wrote:
>
> Matteo Cavalleri wrote:
>
>> hi, i compiled vim from source (from the mercurial repo) with all the
>> latest patches, my system is a ubuntu 13.04 64 bit. when i run vim and
>> load a PHP file i get this error:
>>
>> "classes/ORM/Product.ph
John Marriott wrote:
[html removed]
> Attempting to compile on HP-UX fails after this patch with this
> message:
>
> cc -c -I. -Iproto
> -DHAVE_CONFIG_H -O2 -o objects/regexp.o regexp.c
>
> cc: "regexp_nfa.c",
> line 1966:
Patch 7.3.976
Problem:Can't build on HP-UX.
Solution: Remove modern initialization. (John Marriott)
Files: src/regexp_nfa.c
*** ../vim-7.3.975/src/regexp_nfa.c 2013-05-20 13:44:24.0 +0200
--- src/regexp_nfa.c2013-05-20 13:51:07.0 +0200
***
*** 1961,
Patch 7.3.975
Problem:Crash in regexp parsing.
Solution: Correctly compute the end of allocated memory.
Files: src/regexp_nfa.c
*** ../vim-7.3.974/src/regexp_nfa.c 2013-05-19 22:31:13.0 +0200
--- src/regexp_nfa.c2013-05-20 13:43:37.0 +0200
***
*** 2
On Monday, May 20, 2013 2:34:14 PM UTC+3, Bram Moolenaar wrote:
>
> So the new engine is faster? Or what do the numbers mean?
>
>
>
> My experience is that the new engine is slower. Thus we have work to do
>
> to make it faster.
Just doing "gvim --startuptime a.txt" with regexpengine=0 and
> vim.signs:
> Mapping-like object mapping sign names to vim.Sign attributes. Iterates
> over
> keys, supports item assignment.
If we are at it: The signs feature is broken by design, because its the
user setting "sign ids" - so multiple scripts don't know where to start.
What about add
Charles Peacech wrote:
> On Mon, May 20, 2013 at 5:28 PM, Charles wrote:
> > Hi,
> >
> > In my gvim, the new regexp engine crash gvim for this regexp
> >
> > 0x02a60c72 "htmlSpecialChar "&#\=[0-9A-Za-z]\{1,8};""
> >
> > The crash happens here
> >
> > /*
> > * Allocate and initialize nfa_state_T
On 05/20/2013 02:34 PM, Bram Moolenaar wrote:
The line numbers don't exist. The different types are the same.
Is your compiler broken? Or did you duplicate code?
Probably a compile problem, I'll check it out later. Like I said, it
compiles fine at work.
--
--
You received this message fro
Taro Muraoka wrote:
> I got a report that 970 causes crash when do this:
>
> :echo search("[^A-z]")
>
> # reported at here in Japanese -> https://github.com/vim-jp/issues/issues/386
>
> Yasuhiro Matsumoto try to write a patch to fix this,
> but it seems that there are some other similar pr
Charles Peacech wrote:
> On Mon, May 20, 2013 at 9:12 AM, Ben Fritz wrote:
> >
> > On Sunday, May 19, 2013 12:44:49 PM UTC-5, Bram Moolenaar wrote:
> > > I wrote:
> > >
> > >
> > >
> > > > Patch 7.3.970
> > >
> > >
> > >
> > > All the tests I could do with the new engine pass. However, it is
>
Charles Peacech wrote:
> In my gvim, the new regexp engine crash gvim for this regexp
>
> 0x02a60c72 "htmlSpecialChar "&#\=[0-9A-Za-z]\{1,8};""
>
> The crash happens here
>
> /*
> * Allocate and initialize nfa_state_T.
> */
> static nfa_state_T *
> new_state(c, out, out1)
> int
Ron Aaron wrote:
> Arrgh. This one doesn't even compile for me:
>
> regexp_nfa.c:11010:3: warning: passing argument 3 of ‘addstate’ from
> incompatible pointer type [enabled by default]
> regexp_nfa.c:10088:1: note: expected ‘struct regsub_T *’ but argument is of
> type ‘struct regsub_T *’
>
Ben Fritz wrote:
> On Sunday, May 19, 2013 12:44:49 PM UTC-5, Bram Moolenaar wrote:
> > I wrote:
> >
> > > Patch 7.3.970
> >
> > All the tests I could do with the new engine pass. However, it is
> >
> > noticeable slower than the old engine. If this bothers you, set the
> >
> > 'regexpengin
Matteo Cavalleri wrote:
> hi, i compiled vim from source (from the mercurial repo) with all the
> latest patches, my system is a ubuntu 13.04 64 bit. when i run vim and
> load a PHP file i get this error:
>
> "classes/ORM/Product.php" 495L, 17856C*** Error in `vim': free(): invalid
> next size
Taro Muraoka wrote:
> This makes vim (debug build) slow to startup.
> New NFA engine seems to write huge log files in debug build.
> And it causes this terrible slow down.
>
> Added files are generated like this:
>
> gvim -u NONE -U NONE --noplugin --startuptime startuptime-7.3.XXX.txt
>
>
On Mon, May 20, 2013 at 5:37 PM, Charles wrote:
> On Mon, May 20, 2013 at 5:28 PM, Charles wrote:
>> Hi,
>>
>> In my gvim, the new regexp engine crash gvim for this regexp
>>
>> 0x02a60c72 "htmlSpecialChar "&#\=[0-9A-Za-z]\{1,8};""
>>
>> The crash happens here
>>
>> /*
>> * Allocate and initiali
Patch 7.3.974
Problem:Can't build with ruby 1.8.5.
Solution: Only use ruby_init_stack() when RUBY_INIT_STACK is defined.
(Yukihiro Nakadaira)
Files: src/if_ruby.c
*** ../vim-7.3.973/src/if_ruby.c2013-05-12 14:10:41.0 +0200
--- src/if_ruby.c 2013-05-20
Tooth pik wrote:
> On Mon, May 20, 2013 at 05:17:54AM -0500, tooth pik wrote:
> > I don't know much yet except a huge python (2.7) enabled vim 7.3.793 is
> > getting bombed with a deadly signal ABRT when I try to edit my
> > index.html module
>
> > my first instinct was to disable the runtime/pl
Yukihiro Nakadaira wrote:
> On Mon, May 20, 2013 at 4:37 AM, Christian J. Robinson
> wrote:
>
> > On Sun, 19 May 2013, Bram Moolenaar wrote:
> >
> >
> > Christian J. Robinson wrote:
> >>
> >> [..]/vim73/src/if_ruby.c:739: undefined reference to `ruby_init_stack'
> >>> collect2: ld returned 1
On Mon, May 20, 2013 at 5:17 PM, tooth pik wrote:
> I don't know much yet except a huge python (2.7) enabled vim 7.3.793 is
> getting bombed with a deadly signal ABRT when I try to edit my
> index.html module
>
> my first instinct was to disable the runtime/plugin/tohtml.vim, but I
> still get the
On Mon, May 20, 2013 at 5:28 PM, Charles wrote:
> Hi,
>
> In my gvim, the new regexp engine crash gvim for this regexp
>
> 0x02a60c72 "htmlSpecialChar "&#\=[0-9A-Za-z]\{1,8};""
>
> The crash happens here
>
> /*
> * Allocate and initialize nfa_state_T.
> */
> static nfa_state_T *
> new_state(
Hi All,
Attempting to compile on HP-UX fails after this patch with this
message:
cc -c -I. -Iproto
-DHAVE_CONFIG_H -O2 -o objects/regexp.o regexp.c
cc: "regexp_nfa.c",
line 1966: error 1521: Incorrect initializat
Hi,
In my gvim, the new regexp engine crash gvim for this regexp
0x02a60c72 "htmlSpecialChar "&#\=[0-9A-Za-z]\{1,8};""
The crash happens here
/*
* Allocate and initialize nfa_state_T.
*/
static nfa_state_T *
new_state(c, out, out1)
int c;
nfa_state_T *out;
nfa_state_T
On Mon, May 20, 2013 at 05:17:54AM -0500, tooth pik wrote:
> I don't know much yet except a huge python (2.7) enabled vim 7.3.793 is
> getting bombed with a deadly signal ABRT when I try to edit my
> index.html module
> my first instinct was to disable the runtime/plugin/tohtml.vim, but I
> still
I don't know much yet except a huge python (2.7) enabled vim 7.3.793 is
getting bombed with a deadly signal ABRT when I try to edit my
index.html module
my first instinct was to disable the runtime/plugin/tohtml.vim, but I
still get the deadly signal when I try to edit that file
anybody else?
tp
On Mon, May 20, 2013 at 6:49 PM, Yukihiro Nakadaira <
yukihiro.nakada...@gmail.com> wrote:
> On Mon, May 20, 2013 at 4:37 AM, Christian J. Robinson
> wrote:
>
>> On Sun, 19 May 2013, Bram Moolenaar wrote:
>>
>>
>> Christian J. Robinson wrote:
>>>
>>> [..]/vim73/src/if_ruby.c:739: undefined refe
hi, i compiled vim from source (from the mercurial repo) with all the latest
patches, my system is a ubuntu 13.04 64 bit. when i run vim and load a PHP file
i get this error:
"classes/ORM/Product.php" 495L, 17856C*** Error in `vim': free(): invalid next
size (normal): 0x042cabe0 ***
an
On Mon, May 20, 2013 at 4:37 AM, Christian J. Robinson wrote:
> On Sun, 19 May 2013, Bram Moolenaar wrote:
>
>
> Christian J. Robinson wrote:
>>
>> [..]/vim73/src/if_ruby.c:739: undefined reference to `ruby_init_stack'
>>> collect2: ld returned 1 exit status
>>> link.sh: Linking failed
>>> make:
On 20/05/13 05:53, Ben Fritz wrote:
On Sunday, May 19, 2013 10:18:48 PM UTC-5, mattn wrote:
On Monday, May 20, 2013 11:50:08 AM UTC+9, Ben Fritz wrote:
I'm using the "Vim without Cream" build, version 7.3.822, on Windows 7 64-bit.
And cmd.exe really does stop responding when I pass gvim the -
On Mon, May 20, 2013 at 9:12 AM, Ben Fritz wrote:
>
> On Sunday, May 19, 2013 12:44:49 PM UTC-5, Bram Moolenaar wrote:
> > I wrote:
> >
> >
> >
> > > Patch 7.3.970
> >
> >
> >
> > All the tests I could do with the new engine pass. However, it is
> >
> > noticeable slower than the old engine. If
On 20/05/2013 04:53, Ben Fritz wrote:
On Sunday, May 19, 2013 10:18:48 PM UTC-5, mattn wrote:
On Monday, May 20, 2013 11:50:08 AM UTC+9, Ben Fritz wrote:
I'm using the "Vim without Cream" build, version 7.3.822, on Windows 7 64-bit.
And cmd.exe really does stop responding when I pass gvim the
78 matches
Mail list logo
