Re: Patch 7.3.028
On Thu, Oct 14, 2010 at 9:29 PM, Bram Moolenaar wrote:
Patch 7.3.028 (after 7.3.024)
Problem: Signs don't show up. (Charles Campbell)
Solution: Don't use negative numbers. Also assign a number to signs that
have a name of all digits to avoid using a sign number twice.
Files: src/ex_cmds.c
The following change removes an obsolete comment:
diff --git a/src/ex_cmds.c b/src/ex_cmds.c
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -6556,8 +6556,7 @@
struct sign
{
sign_T *sn_next; /* next sign in list */
-intsn_typenr; /* type number of sign
(negative if not equal
- to name) */
+intsn_typenr; /* type number of sign */
char_u *sn_name; /* name of sign */
char_u *sn_icon; /* name of pixmap */
#ifdef FEAT_SIGN_ICONS
--
Xavier
Les Chemins de Lokoti: http://lokoti.alwaysdata.net
--
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: Inconsistent behaviour of 't' compared to 'f'
I almost created a topic for that a few months ago. Basically, I agree with Sergii. Cheers -- Romain Chossart On Thu, Oct 14, 2010 at 10:33 AM, Sergii Boiko cris.k...@gmail.com wrote: Ingo, thanks for positive comment. Because i'm switching to dvorak and 'f' isn't so useful at this layout as 't'. And this behaviour very annoys me, because 't' is not so handy as 'f'. I don't know vim-script very well to write some prototype, but if someone takes care of it, i will test it thoroughly. On Oct 14, 9:48 am, Ingo Karkat sw...@ingo-karkat.de wrote: It seems like a useful change (that, because it breaks vi-compatibility, would need to be configurable in 'cpoptions'). Before providing a patch, it may be worthwhile to send around a Vimscript prototype (i.e. a mapping override of 't' and ';') first, so that more interested people could easily try this out and voice their opinions. -- regards, ingo -- 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 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: Patch 7.3.028
Xavier de Gaye wrote:
On Thu, Oct 14, 2010 at 9:29 PM, Bram Moolenaar wrote:
Patch 7.3.028 (after 7.3.024)
Problem:Signs don't show up. (Charles Campbell)
Solution: Don't use negative numbers. Also assign a number to signs that
have a name of all digits to avoid using a sign number twice.
Files: src/ex_cmds.c
The following change removes an obsolete comment:
diff --git a/src/ex_cmds.c b/src/ex_cmds.c
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -6556,8 +6556,7 @@
struct sign
{
sign_T *sn_next; /* next sign in list */
-intsn_typenr; /* type number of sign
(negative if not equal
- to name) */
+intsn_typenr; /* type number of sign */
char_u *sn_name; /* name of sign */
char_u *sn_icon; /* name of pixmap */
#ifdef FEAT_SIGN_ICONS
Thanks. I'll include it in a later patch.
--
Microsoft's definition of a boolean: TRUE, FALSE, MAYBE
Embrace and extend...?
/// Bram Moolenaar -- b...@moolenaar.net -- 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///
--
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 7.3.029
Patch 7.3.029
Problem::sort n sorts lines without a number as number zero. (Beeyawned)
Solution: Make lines without a number sort before lines with a number. Also
fix sorting negative numbers.
Files: src/ex_cmds.c, src/testdir/test57.in, src/testdir/test57.ok
*** ../vim-7.3.028/src/ex_cmds.c2010-10-14 21:29:31.0 +0200
--- src/ex_cmds.c 2010-10-15 20:04:25.0 +0200
***
*** 323,329
/* When sorting numbers start_col_nr is the number, not the column
* number. */
if (sort_nr)
! result = l1.start_col_nr - l2.start_col_nr;
else
{
/* We need to copy one line into sortbuf1, because there is no
--- 323,330
/* When sorting numbers start_col_nr is the number, not the column
* number. */
if (sort_nr)
! result = l1.start_col_nr == l2.start_col_nr ? 0
!: l1.start_col_nr l2.start_col_nr ? 1 : -1;
else
{
/* We need to copy one line into sortbuf1, because there is no
***
*** 482,488
* of the match, by temporarily terminating the string there */
s2 = s + end_col;
c = *s2;
! (*s2) = 0;
/* Sorting on number: Store the number itself. */
p = s + start_col;
if (sort_hex)
--- 483,489
* of the match, by temporarily terminating the string there */
s2 = s + end_col;
c = *s2;
! *s2 = NUL;
/* Sorting on number: Store the number itself. */
p = s + start_col;
if (sort_hex)
***
*** 491,499
s = skiptodigit(p);
if (s p s[-1] == '-')
--s; /* include preceding negative sign */
! vim_str2nr(s, NULL, NULL, sort_oct, sort_hex,
! nrs[lnum - eap-line1].start_col_nr,
NULL);
! (*s2) = c;
}
else
{
--- 492,504
s = skiptodigit(p);
if (s p s[-1] == '-')
--s; /* include preceding negative sign */
! if (*s == NUL)
! /* empty line should sort before any number */
! nrs[lnum - eap-line1].start_col_nr = -MAXLNUM;
! else
! vim_str2nr(s, NULL, NULL, sort_oct, sort_hex,
! nrs[lnum - eap-line1].start_col_nr, NULL);
! *s2 = c;
}
else
{
***
*** 6556,6563
struct sign
{
sign_T*sn_next; /* next sign in list */
! int sn_typenr; /* type number of sign (negative if not
equal
! to name) */
char_u*sn_name; /* name of sign */
char_u*sn_icon; /* name of pixmap */
#ifdef FEAT_SIGN_ICONS
--- 6561,6567
struct sign
{
sign_T*sn_next; /* next sign in list */
! int sn_typenr; /* type number of sign */
char_u*sn_name; /* name of sign */
char_u*sn_icon; /* name of pixmap */
#ifdef FEAT_SIGN_ICONS
*** ../vim-7.3.028/src/testdir/test57.in2010-08-15 21:57:29.0
+0200
--- src/testdir/test57.in 2010-10-15 20:12:23.0 +0200
***
*** 53,67
t02: numeric
abc
ab
- a
a321
a123
a122
b321
b123
c123d
123b
c321d
b322b
b321
b321b
--- 53,71
t02: numeric
abc
ab
a321
a123
a122
+ a
+ x-22
b321
b123
+
c123d
+ -24
123b
c321d
+ 0
b322b
b321
b321b
*** ../vim-7.3.028/src/testdir/test57.ok2010-08-15 21:57:29.0
+0200
--- src/testdir/test57.ok 2010-10-15 20:11:42.0 +0200
***
*** 21,26
--- 21,30
a
+
+ -24
+ x-22
+ 0
a122
a123
b123
*** ../vim-7.3.028/src/version.c2010-10-14 21:29:31.0 +0200
--- src/version.c 2010-10-15 20:13:52.0 +0200
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 29,
/**/
--
When danger reared its ugly head,
He bravely turned his tail and fled
Yes, Brave Sir Robin turned about
And gallantly he chickened out
Bravely taking to his feet
He beat a very brave retreat
Bravest of the brave Sir Robin
Petrified of being dead
Soiled his pants then brave Sir Robin
Turned away and fled.
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/ \\\
\\\download, build and distribute -- http://www.A-A-P.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
Re: [DOC FIX] Breaking statement in :finally block prevents propagation of the uncaught exception
ZyX wrote: I noticed that the following code produces no error messages, though thrown exception was not caught by any :catch blocks: function TestFinallyReturn() try throw Test finally Same with :break/:continue in loops and :finally outside of functions return 1 endtry endfunction call TestFinallyReturn() I think this behavior should be documented. Or we should call it a bug. It's not what you would expect, right? This gives an error: while 1 try NotACommand finally echo finally endtry break endwhile But this doesn't: while 1 try NotACommand finally echo finally break endtry endwhile I think that's a bug. -- Life would be so much easier if we could just look at the source code. /// Bram Moolenaar -- b...@moolenaar.net -- 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/// -- 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: sort bug?
Christian Brabandt wrote:
Hi Charles!
On Do, 14 Okt 2010, Charles Campbell wrote:
Bee wrote:
On Oct 13, 10:00 pm, Beebeeyaw...@gmail.com wrote:
On Oct 13, 6:56 pm, Charles E Campbell Jrdrc...@campbellfamily.biz
wrote:
Bee wrote:
sort bug?
vim 7.3.27 Linux
vim 7.3.21 Mac 10.4.11
Select the lines between the rules (including the blank lines) and
sort:
','sort n
1-2-3-4-5-6
xxx yyy: 0
xxx yyy: 1
xxx yyy: 2
xxx yyy: 3
xxx yyy: 4
xxx yyy: 5
xxx yyy: 6
xxx yyy: 7
xxx yyy: 8
xxx yyy: 9
1-2-3-4-5-6
The result is:
1-2-3-4-5-6
xxx yyy: 0
xxx yyy: 1
xxx yyy: 2
xxx yyy: 3
xxx yyy: 4
xxx yyy: 5
xxx yyy: 6
xxx yyy: 7
xxx yyy: 8
xxx yyy: 9
1-2-3-4-5-6
I would expect this and it is what I get when using the shell:
','!sort -n
1-2-3-4-5-6
xxx yyy: 0
xxx yyy: 1
xxx yyy: 2
xxx yyy: 3
xxx yyy: 4
xxx yyy: 5
xxx yyy: 6
xxx yyy: 7
xxx yyy: 8
xxx yyy: 9
1-2-3-4-5-6
I tried your example and was unable to duplicate the problem. Have you
tried putting this in a file, say sort.test:
vim -u NONE -N sort.test
:%sort
I tried that, and I tried using V and selecting all the lines, and each
time I got the I would expect this... result.
Thank you, I did not think to do vim -u NONE -N and...
I then get the expected result!
That means something in my vimrc is causing the sort problem.
I will remember to do that first next time.
Oops!
I copied what you had done and that works, but that is not the case I
was using.
Try it selecting the lines and
:','sort n
Do not forget the n numeric sort option.
With [n] sorting is done on the first decimal number
in the line (after or inside a {pattern} match).
One leading '-' is included in the number.
OK, now that I'm using sort n -- I can duplicate the behavior.
Yes empty lines are considered as they would contain a zero. And in case
another line has the same number, the original order would remain. In
this case, the line with the 0 stays on top. (Really strange is the
result, if you have an empty line, followed by a line containing a zero
followed by an empty line.)
Attached patch fixes that.
Thanks. The number is a long, thus SHRT_MIN is not the smallest number.
To avoid problems with old compilers I'll use MAXLNUM made negative.
Hmm, when there are negative numbers there is another problem, I'll see
if I can fix that as well... Ah, subtracting two longs and storing the
result in an int truncates the number.
--
FIRST HEAD: All right! All right! We'll kill him first and then have tea and
biscuits.
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/ \\\
\\\download, build and distribute -- http://www.A-A-P.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
Re: Inconsistent behaviour of 't' compared to 'f'
On Oct 14, 4:33 am, Sergii Boiko cris.k...@gmail.com wrote:
Ingo, thanks for positive comment. Because i'm switching to dvorak and
'f' isn't so useful at this layout as 't'. And this behaviour very
annoys me, because 't' is not so handy as 'f'.
I don't know vim-script very well to write some prototype, but if
someone takes care of it, i will test it thoroughly.
Here's a quick proof-of-concept, for the ';' command only. It may fail
in some situations. I couldn't get it working right in visual mode:
nnoremap ; :C-Ucall DoubleJumpIfNoMove(v:count1)CR
onoremap ; v:C-Ucall DoubleJumpIfNoMove(v:count1)CR
fun! DoubleJumpIfNoMove(count)
if a:count==1
let curpos=getpos('.')
normal! ;
if curpos==getpos('.')
normal! 2;
else
normal! ;
endif
else
exec 'normal! '.a:count.';'
endif
endfun
--
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: [PATCH] Fix complete() function, and trivial proposal
Kikuchan wrote:
I'm playing with complete() function, and I've found a bug in it.
Acording to :help complete, it says:
inoremap F5 C-R=ListMonths()CR
func! ListMonths()
call complete(col('.'), ['January', 'February', 'March',
\ 'April', 'May', 'June', 'July', 'August', 'September',
\ 'October', 'November', 'December'])
return ''
endfunc
This isn't very useful, but it shows how it works. Note that
an empty string is returned to avoid a zero being inserted.
After loading this inoremap and function, and then I press F5 key,
it shows and selects a first row of the list as a default.
But sometimes when I press F5 again, it shows and selects a *second* row
of the list as a default.
How to reproduce:
F5C-PC-EF5
I think this is a bug because the last C-P sets compl_direction variable
in edit.c to BACKWARD, and it is misused to build up a list for completion
on next complete() function call.
The attached file contains a simple patch to fix it.
# just one line, add 'compl_direction = FORWARD;'
... BTW, I need an extra feature for compelte() function.
The complete() function doesn't allow an element that is empty.
But, I want to show the elements have empty 'word', but non-empty 'abbr'.
so I proposed to add 'empty' key, like 'dup' key.
Bram, could you include this harmless feature, please? ;)
See the attached patch for more details.
It's very simple, and it doesn't change any default behavior.
I'll add a note in the todo list to look into this.
--
ZOOT: I'm afraid our life must seem very dull and quiet compared to yours.
We are but eightscore young blondes, all between sixteen and
nineteen-and-a-half, cut off in this castle, with no one to protect us.
Oooh. It is a lonely life ... bathing ... dressing ... undressing ...
making exciting underwear
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/ \\\
\\\download, build and distribute -- http://www.A-A-P.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
Re: Inconsistent behaviour of 't' compared to 'f'
On Oct 15, 2:07 pm, Ben Fritz fritzophre...@gmail.com wrote:
On Oct 14, 4:33 am, Sergii Boiko cris.k...@gmail.com wrote:
Ingo, thanks for positive comment. Because i'm switching to dvorak and
'f' isn't so useful at this layout as 't'. And this behaviour very
annoys me, because 't' is not so handy as 'f'.
I don't know vim-script very well to write some prototype, but if
someone takes care of it, i will test it thoroughly.
Here's a quick proof-of-concept, for the ';' command only. It may fail
in some situations. I couldn't get it working right in visual mode:
And here is a more complete solution, with visual mode and the ,
motion also working:
nnoremap ; :C-Ucall DoubleJumpIfNoMove(v:count1, ';')CR
onoremap ; v:C-Ucall DoubleJumpIfNoMove(v:count1, ';')CR
xnoremap ; :C-Ucall DoubleJumpIfNoMove(v:count1, ';', 1)CR
nnoremap , :C-Ucall DoubleJumpIfNoMove(v:count1, ',')CR
onoremap , v:C-Ucall DoubleJumpIfNoMove(v:count1, ',')CR
xnoremap , :C-Ucall DoubleJumpIfNoMove(v:count1, ',', 1)CR
fun! DoubleJumpIfNoMove(count, op, ...)
let cmdprefix=''
if a:0
normal! gv
endif
if a:count==1
let curpos=getpos('.')
exec 'normal!' a:op
if curpos==getpos('.')
exec 'normal! 2'.a:op
endif
else
exec 'normal! '.a:count.a:op
endif
endfun
--
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
