Thanks for your replies! Indeed http://repo.or.cz/w/vim_extended.git has
7.2.446 patched with variable tabstops. The easiest way to get it
is to download a tarball of the most recent snapshot from the shortlog.
I can't thank Matthew Winn (and Lech Lorens and Markus Heidelberg) enough
for this. Ho
On Friday, May 24, 2013 2:00:29 PM UTC-7, toothpik wrote:
> On Fri, May 24, 2013 at 12:22:44PM -0700, Dmitry Gorbik wrote:
>
> > Sorry, but think this change without keeping an original behavior
>
> > may just be too fast. Consider a workflow when you deal with files
>
> > with a lot if lines. T
I just thought that it will have a huge psychological effect. Right now the
brain is adjusted to the way numbers go from 0. Seeing some arbitrary number
right near your code is not the best thing. Bram says it's annoying for people
when we mess with existing settings, isn't this one of them? A l
I wrote a patch to make NFA state dump more pretty.
Before patch:
> (11) NFA_MOPEN(0) (-991) (id=11)
> (10) NFA_SPLIT (-1024) (id=10)
> ( 8) NFA_MOPEN(1) (-990) (id=8)
> ( 7) NFA_SPLIT (-1024) (id=7)
> ( 1) CHAR(f) (102) (id=1)
> ( 2)
Thank you for your input.
On Sat, May 25, 2013 at 1:17 AM, Marc Weber wrote:
> I think its worth mentioning that all the timings above do include
> startup times of the interpreter?
I used a ~38M text file, startup time doesn't really enter here.
> In your gist the only defined command is the v
Excerpts from glts's message of Sat May 25 00:56:56 +0200 2013:
> Please refer to that web site for more information.
I think its worth mentioning that all the timings above do include
startup times of the interpreter?
In your gist the only defined command is the vim command line, so there
is no
Hi,
there is simple but straightforward "Benchmark of Regex Libraries" at
http://lh3lh3.users.sourceforge.net/reb.shtml
I measured search durations for both regexp engines in Vim 7.3.1010,
using the same regular expressions and the same data they used. I added
one simpler test, which is listed in
Patch 7.3.1012
Problem:\Z does not work properly with the new regexp engine.
Solution: Make \Z work. Add tests.
Files: src/regexp_nfa.c, src/testdir/test95.in, src/testdir/test95.ok
*** ../vim-7.3.1011/src/regexp_nfa.c2013-05-24 21:59:50.0 +0200
--- src/regexp_nfa.c20
I have improved logging of NFA regexp engine.
- refine macros for logging.
- add comments for logging.
Please check attached patch.
--
--
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
On Fri, May 24, 2013 at 12:22:44PM -0700, Dmitry Gorbik wrote:
> Sorry, but think this change without keeping an original behavior
> may just be too fast. Consider a workflow when you deal with files
> with a lot if lines. This is not too great for the line gutter to
> take a lot of space. This is
On Fr, 24 Mai 2013, Christian Brabandt wrote:
> On Fr, 24 Mai 2013, Ein Brown wrote:
>
> > The SO question has more details:
> > http://stackoverflow.com/questions/16592654/in-vim-why-is-move-randomly-corrupting-my-folds
> >
> > at the bottom of the SO question (under 'edit') I explain ways to
Sorry, but think this change without keeping an original behavior may just be
too fast. Consider a workflow when you deal with files with a lot if lines.
This is not too great for the line gutter to take a lot of space. This is
actually why I use relative numbers - useful and doesn't take much s
Hi,
The #ifdef __QNXNTO__ block in src/gui.c:gui_do_fork()
is missing the #ifdef FEAT_GUI_GTK block that is in
the non-QNX version. As such gui_mch_init_check()
is never called and things never get rolling.
I just removed the QNX specific block and used the
generic code and things are fine. Th
Hi Ein!
On Fr, 24 Mai 2013, Ein Brown wrote:
> Hi, I have encountered a bug where my folds become 'corrupted' and
> unrecognized by vim. I looks like this is caused by using :move on a closed
> fold under the right circumstances.
>
> The SO question has more details:
> http://stackoverflow.co
Patch 7.3.1011
Problem:New regexp engine is inefficient with multi-byte characters.
Solution: Handle a character at a time instead of a byte at a time. Also
make \Z partly work.
Files: src/regexp_nfa.c, src/testdir/test95.in, src/testdir/test95.ok
*** ../vim-7.3.1010/src/
Please ignore this report.
Sorry, it was reported at past.
I realize it just now.
--
--
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
I found a dust abount 'regexpengine' in options.txt, and removed it.
Please check an attached patch.
--
--
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 Friday, May 24, 2013 10:07:09 AM UTC-5, Andrei Olsen wrote:
> kl. 04:17:42 UTC+2 mandag 20. mai 2013 skrev Ben Fritz følgende:
>
> > 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 -f
Hi, I have encountered a bug where my folds become 'corrupted' and unrecognized
by vim. I looks like this is caused by using :move on a closed fold under the
right circumstances.
The SO question has more details:
http://stackoverflow.com/questions/16592654/in-vim-why-is-move-randomly-corrupting
Patch 7.3.1010
Problem:New regexp: adding \Z makes every character match.
Solution: Only apply ireg_icombine for composing characters.
Alsl add missing change from patch 1008. (Ken Takata)
Files: src/regexp_nfa.c, src/testdir/test95.in, src/testdir/test95.ok
*** ../vim-7.3
Hi,
I sent this patch to the vim.vim maintainer, Charles Campbell, but
didn't get a response. Resubmitting to vim_dev.
On Fri, May 10, 2013 at 1:51 PM, I wrote:
> Dear Charles Campbell,
>
> the regular expression for "vimNumber" in syntax/vim.vim is wrong.
>
> Attached patch fixes it.
>
> For ref
Dominique Pelle wrote:
> Bram Moolenaar wrote:
>
> > With the few files I received I already found two bugs in the new regexp
> > engine.
> >
> > But I received only 7 files. I need many more! So now asking everyone,
> > not just syntax file maintainers, to send me files for testing. Please
>
Patch 7.3.1009
Problem:Compiler warning for ambiguous else.
Solution: Add curly braces.
Files: src/if_py_both.h
*** ../vim-7.3.1008/src/if_py_both.h2013-05-21 22:38:14.0 +0200
--- src/if_py_both.h2013-05-24 18:54:32.0 +0200
***
*** 2163,2169
--
kl. 04:17:42 UTC+2 mandag 20. mai 2013 skrev Ben Fritz følgende:
> 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 -f flag. No
> prompt appears until Vim closes. Any typing done in the cmd.exe window d
Yasuhiro Matsumoto wrote:
> OK, I'll do it.
> However I doubt that there are some cases that new regexp engine is
> slower than original. This change make be possible to work with html
> file syntax, but re=2 seems to be slower than re=1.
The NFA engine is known to be slower on simple patterns,
Ken Takata wrote:
> 2013/05/24 Fri 5:43:25 UTC+9 Bram Moolenaar wrote:
> > Patch 7.3.1008
> > Problem:Test 95 fails on MS-Windows.
> > Solution: Set 'nomore'. Change \i to \f. Change multi-byte character to
> > something that is not matching \i. (Ken Takata)
> > Files: src
26 matches
Mail list logo
