Re: Patch 7.3.1008
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/testdir/test95.in, src/testdir/test95.ok The following hunk is missing: diff --git a/src/testdir/test95.in b/src/testdir/test95.in --- a/src/testdir/test95.in +++ b/src/testdir/test95.in @@ -7,7 +7,7 @@ STARTTEST :so small.vim :so mbyte.vim -:set nocp encoding=utf-8 viminfo+=nviminfo +:set nocp encoding=utf-8 viminfo+=nviminfo nomore : tl is a List of Lists with: :regexp pattern :text to test the pattern on Right, I managed to miss that part when fixing the multi-byte issue. It will come later. -- Hacker: Someone skilled in computer programming (good guy). Cracker: A hacker that uses his skills to crack software (bad guy). /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Problems of new regexp engine (that we know)
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, but much faster on complicated patterns. Especially patterns with * or \+ should be faster, because the backtracking engine makes many attempts and retries, while the NFA engine explores all possible solutions in parallel. After tuning and fixing bugs I want to only use the NFA engine for complicated patterns, then we should really see the advantage. The line length also matters. Of course we can't use the NFA engine for items it does not support, thus a mix of * and any not supported item would result in falling back to the (slow) old engine. -- It is too bad that the speed of light hasn't kept pace with the changes in CPU speed and network bandwidth. -- wie...@porcupine.org /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Windows doesn't support -f option
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 does not appear until Vim closes. When Vim closes, any text typed while Vim was open does appear on the command line. I'm a bit baffled as why it works for you. I tried Vim without Cream build 822 and 829 and none of them stop when I pass -f flag from Windows command prompt (cmd.exe). I should add that -f works fine with any build if I start it from MSYS shell. -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Patch 7.3.1009
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
--- 2163,2171
TabPageObject *tabObject = self-tabObject;
if (tabObject)
+ {
Py_DECREF((PyObject *)(tabObject));
+ }
DESTRUCTOR_FINISH(self);
}
*** ../vim-7.3.1008/src/version.c 2013-05-23 22:43:03.0 +0200
--- src/version.c 2013-05-24 18:58:10.0 +0200
***
*** 730,731
--- 730,733
{ /* Add new patch number below this line */
+ /**/
+ 1009,
/**/
--
BEDEVERE:Why do you think she is a witch?
SECOND VILLAGER: She turned me into a newt.
BEDEVERE:A newt?
SECOND VILLAGER: (After looking at himself for some time) I got better.
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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 Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: To all syntax file maintainers: examples needed
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 read the quoted text above for what the file should contain. Hi Bram Attached is a sample file for the 'gprof' file type, to test the new regexp engine. The 'gprof' syntax is not part of the official vim, but I have a plugin here which you may want to include to the official vim if it is useful enough: http://www.vim.org/scripts/script.php?script_id=4077 Since gprof file does not have an official extension, you need to do :setfiletype gprof, or add the following lines to $VIMRUNTIME/scripts.vim to automatically recognize gprof files: Thanks. I'll include the gprof syntax and ftplugin. The gprof_sample.txt is too big and repetitive, I'll throw away some lines. And rename it to gprof_sample, otherwise it gets text filetype. -- BEDEVERE: Wait. Wait ... tell me, what also floats on water? ALL: Bread? No, no, no. Apples gravy ... very small rocks ... ARTHUR: A duck. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Patch: vim.vim syntax file
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 reference, the exact regexp to match integer and floating point numbers in Vim script is /[+-]\=\d\+\%(\.\d\+\%([eE][+-]\=\d\+\)\=\)\=/. Best, David Bürgin The second patch applies to the same file. It removes a few mistaken command keywords like :comment and :quote. Thanks. -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. fix-vim-number-syntax.patch Description: Binary data fix-vim-commands-syntax.patch Description: Binary data
Patch 7.3.1010
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.1009/src/regexp_nfa.c2013-05-23 22:25:10.0 +0200
--- src/regexp_nfa.c2013-05-24 20:20:14.0 +0200
***
*** 2859,2865
List *listtbl[2][2];
List *ll;
int listid = 1;
! int endnode = 0;
List *thislist;
List *nextlist;
List *neglist;
--- 2859,2865
List *listtbl[2][2];
List *ll;
int listid = 1;
! int endnode;
List *thislist;
List *nextlist;
List *neglist;
***
*** 3192,3204
case NFA_MULTIBYTE:
case NFA_COMPOSING:
! switch (t-state-c)
! {
! case NFA_MULTIBYTE: endnode = NFA_END_MULTIBYTE; break;
! case NFA_COMPOSING: endnode = NFA_END_COMPOSING; break;
! default:endnode = 0;
! }
!
result = OK;
sta = t-state-out;
len = 1;
--- 3192,3198
case NFA_MULTIBYTE:
case NFA_COMPOSING:
! endnode = t-state-c + 1;
result = OK;
sta = t-state-out;
len = 1;
***
*** 3206,3212
{
if (reginput[len-1] != sta-c)
{
! result = OK - 1;
break;
}
len++;
--- 3200,3206
{
if (reginput[len-1] != sta-c)
{
! result = FAIL;
break;
}
len++;
***
*** 3215,3225
/* if input char length doesn't match regexp char length */
if (len -1 n || sta-c != endnode)
! result = OK - 1;
end = t-state-out1; /* NFA_END_MULTIBYTE or
NFA_END_COMPOSING */
/* If \Z was present, then ignore composing characters */
! if (regflags RF_ICOMBINE)
result = 1 ^ sta-negated;
ADD_POS_NEG_STATE(end);
break;
--- 3209,3219
/* if input char length doesn't match regexp char length */
if (len -1 n || sta-c != endnode)
! result = FAIL;
end = t-state-out1; /* NFA_END_MULTIBYTE or
NFA_END_COMPOSING */
/* If \Z was present, then ignore composing characters */
! if (ireg_icombine endnode == NFA_END_COMPOSING)
result = 1 ^ sta-negated;
ADD_POS_NEG_STATE(end);
break;
*** ../vim-7.3.1009/src/testdir/test95.in 2013-05-23 22:43:03.0
+0200
--- src/testdir/test95.in 2013-05-24 20:18:13.0 +0200
***
*** 7,13
STARTTEST
:so small.vim
:so mbyte.vim
! :set nocp encoding=utf-8 viminfo+=nviminfo
: tl is a List of Lists with:
:regexp pattern
:text to test the pattern on
--- 7,13
STARTTEST
:so small.vim
:so mbyte.vim
! :set nocp encoding=utf-8 viminfo+=nviminfo nomore
: tl is a List of Lists with:
:regexp pattern
:text to test the pattern on
***
*** 35,45
:call add(tl, ['\f\+', '*Ÿfname ', 'fname'])
:call add(tl, ['\%#=1\f\+', '*Ÿfname ', 'fname'])
: Combining different tests and features
:call add(tl, ['[^[=a=]]\+', 'ddaãâbcd', 'dd'])
: Run the tests
-
:
:for t in tl
: let l = matchlist(t[1], t[0])
--- 35,47
:call add(tl, ['\f\+', '*Ÿfname ', 'fname'])
:call add(tl, ['\%#=1\f\+', '*Ÿfname ', 'fname'])
+ : Test \Z
+ :call add(tl, ['ú\Z', 'x'])
+
: Combining different tests and features
:call add(tl, ['[^[=a=]]\+', 'ddaãâbcd', 'dd'])
: Run the tests
:
:for t in tl
: let l = matchlist(t[1], t[0])
*** ../vim-7.3.1009/src/testdir/test95.ok 2013-05-23 22:43:03.0
+0200
--- src/testdir/test95.ok 2013-05-24 20:18:55.0 +0200
***
*** 9,12
--- 9,13
OK - \%#=1\i\+
OK - \f\+
OK - \%#=1\f\+
+ OK - ú\Z
OK - [^[=a=]]\+
*** ../vim-7.3.1009/src/version.c 2013-05-24 18:58:39.0 +0200
--- src/version.c 2013-05-24 20:21:52.0 +0200
***
*** 730,731
--- 730,733
{ /* Add new patch number below this line */
+ /**/
+ 1010,
/**/
--
Never under any circumstances take a sleeping pill
and a laxative on the same
bug with using :move on folds?
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-my-folds at the bottom of the SO question (under 'edit') I explain ways to run into the bug without the Alt-Up / Alt-Down mapping. Best, Ein -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: New feature: absolute line number in relativenumber for the current line
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 space. I hope you will consider this case, Thanks -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: New feature: absolute line number in relativenumber for the current line
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 actually why I use relative numbers - useful and doesn't take much space. I hope you will consider this case, Thanks I too dislike this feature -- could we maybe have an option to get the zero back? -- _|_ _ __|_|_ ._ o| |_(_)(_)|_| ||_)|| | -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Some performance figures for the new regexp engine
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 the final column (Word) below. Please refer to that web site for more information. URI EmailDateSum3 URI|EmailWord re=1 16.34 13.654.07 34.06 29.460.49 re=2 92.039.754.47 106.25 105.395.22 Python 2.7.32.695.171.018.877.723.40 Perl 5.14.2 0.350.330.321.008.120.31 GNU egrep 2.10 0.210.160.560.93 10.860.03 The figures (in s) are averages of five runs each, on Linux, 64-bit i7-2700K CPU @ 3.50GHz x 8. (The Python, Perl, and egrep figures are just for comparison with the original benchmark.) I made a gist with the necessary materials here: https://gist.github.com/glts/5646749 Best, -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Some performance figures for the new regexp engine
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 way to reproduce your figures. Thus your test is almost void :( How to write a benchmark: - try to make the startup time neglegible, thus don't run 5 times, run 1000 times, and do that within vim/python/ loop so that startup only happens once. Starting vim takes less than a second, your runs are 10 sec most of the time, so I guess that re=1 vs re=2 is representative for your cases. 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.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Some performance figures for the new regexp engine
Thank you for your input. On Sat, May 25, 2013 at 1:17 AM, Marc Weber marco-owe...@gmx.de 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 vim command line, so there is no way to reproduce your figures. perl script.pl 'pattern' /path/to/data /dev/null python script.py 'pattern' /path/to/data /dev/null egrep 'pattern' /path/to/data /dev/null Starting vim takes less than a second, your runs are 10 sec most of the time, so I guess that re=1 vs re=2 is representative for your cases. Vim startup time is 0.01s. -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
NFA pretty dump
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) CHAR(o) (111) (id=2)
( 3) CHAR(o) (111) (id=3)
( 9) NFA_MCLOSE(1) (-980) (id=9)
(10) NFA_SPLIT (-1024) (id=10)
( 4) CHAR(b) (98) (id=4)
( 5) CHAR(a) (97) (id=5)
( 6) CHAR(r) (114) (id=6)
( 9) NFA_MCLOSE(1) (-980) (id=9)
(12) NFA_MCLOSE(0) (-981) (id=12)
( 0) NFA_MATCH (-1023) (id=0)
After 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) | | +-CHAR(o) (111) (id=2)
( 3) | | +-CHAR(o) (111) (id=3)
( 9) | | +-NFA_MCLOSE(1) (-980) (id=9)
(10) | | +-NFA_SPLIT (-1024) (id=10)
( 4) | +-CHAR(b) (98) (id=4)
( 5) | +-CHAR(a) (97) (id=5)
( 6) | +-CHAR(r) (114) (id=6)
( 9) | +-NFA_MCLOSE(1) (-980) (id=9)
(12) +-NFA_MCLOSE(0) (-981) (id=12)
( 0) +-NFA_MATCH (-1023) (id=0)
This will be great help to debugging NFA with complex patterns.
--
--
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 Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
# HG changeset patch
# Parent e782f5be8263bed448060c473adaec560ec83aed
diff -r e782f5be8263 src/regexp_nfa.c
--- a/src/regexp_nfa.c Thu May 23 22:43:08 2013 +0200
+++ b/src/regexp_nfa.c Sat May 25 08:54:21 2013 +0900
@@ -170,7 +170,8 @@
#ifdef DEBUG
static void nfa_set_code __ARGS((int c));
static void nfa_postfix_dump __ARGS((char_u *expr, int retval));
-static void nfa_print_state __ARGS((FILE *debugf, nfa_state_T *state, int ident));
+static void nfa_print_state __ARGS((FILE *debugf, nfa_state_T *state));
+static void nfa_print_state2 __ARGS((FILE *debugf, nfa_state_T *state, garray_T *indent));
static void nfa_dump __ARGS((nfa_regprog_T *prog));
#endif
static int *re2post __ARGS((void));
@@ -1841,29 +1842,75 @@
* Print the NFA starting with a root node state.
*/
static void
-nfa_print_state(debugf, state, ident)
+nfa_print_state(debugf, state)
FILE *debugf;
nfa_state_T *state;
-int ident;
{
-int i;
+garray_T indent;
+
+ga_init2(indent, 1, 64);
+ga_append(indent, '\0');
+nfa_print_state2(debugf, state, indent);
+fclose(debugf);
+ga_clear(indent);
+}
+
+static void
+nfa_print_state2(debugf, state, indent)
+FILE *debugf;
+nfa_state_T *state;
+garray_T *indent;
+{
+char_u *p;
if (state == NULL)
return;
fprintf(debugf, (%2d), abs(state-id));
-for (i = 0; i ident; i++)
- fprintf(debugf, %c, ' ');
+
+/* Output indent */
+p = (char_u *)indent-ga_data;
+if (indent-ga_len = 3)
+{
+ int last = indent-ga_len - 3;
+ char_u save[2];
+
+ STRNCPY(save, p[last], 2);
+ STRNCPY(p[last], +-, 2);
+ fprintf(debugf, %s, p);
+ STRNCPY(p[last], save, 2);
+}
+else
+ fprintf(debugf, %s, p);
nfa_set_code(state-c);
-fprintf(debugf, %s %s (%d) (id=%d)\n,
- state-negated ? NOT : , code, state-c, abs(state-id));
+fprintf(debugf, %s%s (%d) (id=%d)\n,
+ state-negated ? NOT : , code, state-c, abs(state-id));
if (state-id 0)
return;
state-id = abs(state-id) * -1;
-nfa_print_state(debugf, state-out, ident + 4);
-nfa_print_state(debugf, state-out1, ident + 4);
+
+/* grow indent for state-out */
+indent-ga_len -= 1;
+if (state-out1)
+ ga_concat(indent, | );
+else
+ ga_concat(indent, );
+ga_append(indent, '\0');
+
+nfa_print_state2(debugf, state-out, indent);
+
+/* replace last part of indent for state-out1 */
+indent-ga_len -= 3;
+ga_concat(indent, );
+ga_append(indent, '\0');
+
+nfa_print_state2(debugf, state-out1, indent);
+
+/* shrink indent */
+indent-ga_len -= 3;
+ga_append(indent, '\0');
}
/*
@@ -1876,10 +1923,7 @@
FILE *debugf = fopen(LOG.log, a);
if (debugf != NULL)
-{
- nfa_print_state(debugf, prog-start, 0);
- fclose(debugf);
-}
+ nfa_print_state(debugf, prog-start);
}
#endif /* ENABLE_LOG */
#endif /* DEBUG */
@@ -3519,7 +3563,7 @@
#endif
fprintf(f, \tInput text is \%s\ \n, reginput);
fprintf(f, ===\n\n\n\n\n\n\n);
-
Re: New feature: absolute line number in relativenumber for the current line
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 lot of people who use relative number at the moment are used to check the current line number in the status bar. Moving this to another place breaks people habits. Yes, they will still be able to use status bar for that, but they get some distractive information. 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. 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 space. I hope you will consider this case, Thanks I too dislike this feature -- could we maybe have an option to get the zero back? -- _|_ _ __|_|_ ._ o| |_(_)(_)|_| ||_)|| | -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: New feature: absolute line number in relativenumber for the current line
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. 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 space. I hope you will consider this case, Thanks I too dislike this feature -- could we maybe have an option to get the zero back? -- _|_ _ __|_|_ ._ o| |_(_)(_)|_| ||_)|| | 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 lot of people who use relative number at the moment are used to check the current line number in the status bar. Moving this to another place breaks people habits. Yes, they will still be able to use status bar for that, but they get some distractive information. -- -- 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 Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
