dv} splits multibyte characters

[Urtica dioica]

Using UTF-8, start from an empty file and type:

grádv}

And your buffer should now contain the lonely byte , which is the last byte 
of the entered character á in UTF-8.

I've only managed to trigger this using (possibly numbered) dv} or cv} or yv} 
where it would normally delete up to (but not including) the last character in 
the file. Other commands, like dv) dv$ dv don't seem to trigger the bug.

-- 
-- 
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/d/optout.

Re: Patch 7.4.2259

[Urtica dioica]

I do like the idea for the feature. I tried it, it has some bugs, but they'll 
get ironed out eventually.

But I've gotta ask, does no one else use search command line history? The new 
bindings override the old forward/backward command history bindings (and that 
are still used by the other command lines). The only way to access search 
history now is with the command line window ().

Is that the plan? I won't fight the decision, but I will say I'm not happy 
losing the old (useful) bindings.

-- 
-- 
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/d/optout.

Re: Patch 7.4.1087

[Urtica dioica]

> Attached patch would fix this issue.
> Please confirm this patch.

Works for me. Thanks very much.

-- 
-- 
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/d/optout.

Re: Patch 7.4.1087

[Urtica dioica]

7.4.1087 caused a regression (still present in 7.4.1627).

hello 1
world
--- ljx
hello 2
wrld

Using j or k after a regular increment/decrement that moves the cursor right 
returns to the old column.

-- 
-- 
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/d/optout.

Re: Patch 7.4.765

[Urtica dioica]

This patch introduced regressions unrelated to visual increment/decrement.

When there's no number under the cursor or to the right, ^A and ^X are supposed 
to do nothing and fail the mapping/macro. Instead, failure doesn't occur and 
the cursor moves left:


--- $@='C-A.ra'CR
#a##

If the cursor is already at the start of the line, the ruler reports it moves 
to column 0. If you press h after that, the column number becomes negative.

If you try to do an edit from the illegal column, it crashes Vim.

#
--- C-Aia
Vim: Caught deadly signal SEGV

-- 
-- 
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/d/optout.

Re: Patch 7.4.765

[Urtica dioica]

 This patch introduced regressions unrelated to visual increment/decrement.

I should have checked against the latest patches first. The cursor movement and 
crashes still happen in the latest Vim, but against Christian Brabandt's latest 
patches those no longer occur. However, ^A and ^X no longer fail 
mappings/macros, so that part stands.

-- 
-- 
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/d/optout.

Re: Patch 7.4.754

[Urtica dioica]

I've had some time to play with this patch.

1. Let's crash Vim.

8
--- vC-A.xu
Segmentation Fault

2. Visual areas change from dot repeats. gv can confirm the changed areas.

1
1
1
--- VC-A.
3
2
1



--- C-V2$C-A
1323
1323

3. Dot repeat of gC-A does nothing sensible.

0
0
0
0
--- VGgC-A..
4
3
4
5

4. With nf=hex the letters [A-Fa-f] outside a number prevent searching farther 
right in the line for a real number.

f 1
--- vC-ArgvC-A
g 2

5. It's interesting that it searches right of the visual area now. I'm not sure 
I *object*, but I didn't expect you to do that. In any case, think of these 
more as documentation than bug reports.

#1
--- v9C-A.
#100

Compare to this. v$C-A could be a valuable idiom.

#1
--- v$9C-A.
#19

-- 
-- 
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/d/optout.

Re: Patch 7.4.754

[Urtica dioica]

There was another one I meant to add but forgot. Numbered dot in block and line 
visual acts on an expanded region instead of changing the number argument.

Line visual examples will be complicated by the changing visual area I 
mentioned earlier, but you can see what's going on.

1
1
1
1
1
--- VC-A3.
3
2
2
2
1


--- C-VC-A3.
2121

Single-line character visual works right sometimes. No bug here.


--- vC-A3.
5111

But if you expand the area it misbehaves.

1
--- vlC-A3.
12121

This leaves you in visual mode.

11
11
11
--- C-VjC-A2.
21
21
11

Totally glitched out.

11
11
11
--- vjC-A2.cGhelloEsc
31
22
hello

-- 
-- 
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/d/optout.

Re: Patch 7.4.754

[Urtica dioica]

 Here is another update, that fixes the problem, that vim_str2nr always 
 checks all available chars for numbers, making it impossible to select 
 less numbers.

I'm going from this patch. I've triggered a couple bugs where I couldn't figure 
out how to repeat them. I'll have to keep trying.

1. The cursor should really end at the top-left, probably at ` (maybe ' for 
line visual, I don't know). This is what you expect from most visual mode 
commands, and it's much more useful for dot-repeat.

This should act on the same area both times, but instead:

1
1
--- C-VjC-A.
2
3

This should act on the next column over:

1 1
1 1
--- C-VjC-Aw.
2 1
2 2

Some of the cursor positions right now are especially silly. Here I insert to 
the end of the line:

1
1
--- VjC-AiaEsc
2
2a

Or you can crash vim:

1
--- YpxVkC-Aa!
segmentation fault

Or like this:

10
10
10
--- VjC-Xa!
segmentation fault

2. The new dot repeat area is glitchy.

You expect visual mode dot repeats to act on a 1v area. This dot repeat shrinks 
the visual area:

1
1
1
1
--- VjjC-AgvC-A{.gvC-A
5
5
3
1

It's different in the other visual modes:

1
1
1
--- vjjC-A(.
3
2
2

3. Octal detection in decimal numbers is annoying. I'm not sure I'd call this a 
bug, but it's weird:

107
--- lvlC-A
1010

A real bug, even weirder:

101
--- lvC-A
1011

4. It's very picky now about not affecting digits right of the visual area... 
unless hex is detected.

A funny example where the column changed is different in each row, and the hex 
row changes outside of the visual area:

0x1
001
aaa
--- :se nf+=alphaCRC-VjjlC-A
0x2
011
baa

5. It's impossible to increment a series of right-aligned numbers.

1
19
119
--- :%ri3CR{C-V3eC-A
  1
 19
120

The way I'd expect it to work, it would look for the left-most incrementable 
number in each line, assuming it's inside the visual area. As it is, it ignores 
any line where there's not a number *exactly* aligned to the left side.

These numbers are both in the visual area, but only the left-aligned one is 
recognized:

1=
=1
--- C-VjlC-A
2=
=1

6. The position of the cursor within identical visual areas still matters.

Similar to the one above:

1
19
119
--- :%ri3CR{$C-VGC-A
  1
 19
219

7. The entire screen is redrawn every time, even for single-line edits that 
affect zero or one characters.

-- 
-- 
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/d/optout.

Re: Patch 7.4.754

[Urtica dioica]

I've only been playing with this for a few minutes, but there are lots of 
problems.

1. vgC-A with :se nf=alpha doesn't do letters.

a
a
a
--- :se nf=alphaCRVGgC-A
b
b
b

2. Minus signs are never added or removed.

0
--- VC-X
1

Another:

-1
--- V3C-A
-2

3. Even if multiple columns are selected, it acts on only one column. The 
column it selects can be unusual.

This makes sense:

0x9
0x9
0x9
--- C-V3$C-A
0xa
0xa
0xa

This uses the same visual area, but with a different result:

0x9
0x9
0x9
--- $C-V++C-A
0x10
0x10
0x10

This increments a number that wasn't in the visual area:

0 0
0 0
0 0
--- $v++C-A
0 1
0 1
0 1

4. If you dot repeat, you get an ordinary C-X/C-A.

0x0
0x0
--- $C-Vj10C-A.
0x10
0x1a

Note that the cursor ends at the bottom-right, opposite of most visual mode 
commands. This makes useful dot repeats difficult.

5. Overflow.

1
1
1
--- VGgC-X
0
18446744073709551615
18446744073709551614

-- 
-- 
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/d/optout.

Re: Patch 7.4.754

[Urtica dioica]

2015年6月25日木曜日 12時53分53秒 UTC-6 Christian Brabandt:
 Thanks. I'll fix it.

Cool.

Here's another funny bug. I ^I's are all normal 8-space tabs:

a^I1
aa^I1
aa1
aa^I1
a^I1
--- $C-V4jC-A
a^I2
aa^I1
aa2
aa^I1
a^I2

Lines 2 and 4 visually align because of the tabs, but no incrementing occurs. 
Line 3 is not in the visual area, but has a number as the third character, so 
it gets incremented.

-- 
-- 
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/d/optout.

Re: Patch 7.4.754

[Urtica dioica]

Found another one. If the column we're adding to has a line that doesn't extend 
long enough, every line after that will be ignored.

Lines 1-2, 4-5 are indented. The middle line has no character in column 2. The 
middle line gets incremented despite not being in the visual area, while the 
lines below are ignored:

 1
 1
1
 1
 1
--- $C-VGC-A
 2
 2
2
 1
 1

It's also interesting how line visual works. It only applies to lines that 
start with a number:

1
--- VC-A
1

-- 
-- 
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/d/optout.

segfault with nfa

[Urtica dioica]

When using the NFA engine, the following seems to cause a segfault:

/\ze*

If you have set incsearch, you don't even need to press Enter.

-- 
-- 
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/d/optout.

Regression in numbered gr

[Urtica dioica]

It seems the gr command with a number argument now mistakenly replaces only 
character, and runs the rest of the number in normal mode.

Running a command like 4gro used to make . Now it replaces one o, runs 
the o command (makes a new line), puts oo in the new line, and ends in insert 
mode. Or say 7gr/ replaces one character with /, runs /, and leaves the 
remaining 5 /'s on the command line.

This bug seems to have been introduced in 7.4.171.

-- 
-- 
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/d/optout.

Re: Patch 7.4.100

[Urtica dioica]

25 a's is a lot, but if you make the first multi nongreedy:

\v^(a{-2,})\1+$

Now the NFA engine can't handle multiples of 3 either, and it errs/differs from 
the old engine after only 9 a's.

-- 
-- 
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: Patch 7.4.100

[Urtica dioica]

\v^(a*)\1$ seems to work as expected now.

\v^(aa+)\1+$ works closer to how I'd expect. It matches all multiples of 2 and 
3, but still doesn't match multiples of higher primes like 5 or 7, so 25/35/49 
as don't match. Old engine still matches those numbers as expected.

-- 
-- 
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: Regex matching composite numbers no longer works with NFA engine

[Urtica dioica]

The problem is the NFA engine can't figure out how much a multi in a submatch 
should match.

I made a simplified case. We'll make a bunch of lines full of as. This regex 
that uses the old engine matches lines with an even number of as:

\%#=1\v^(a*)\1$

This makes sense. The submatch can match any number of as. The backreference 
just tries to double it.

However, if you don't specify the engine, Vim defaults to NFA, and you get the 
power of 2 plus 2 behavior:

\v^(a*)\1$

For instance, this won't match a line of 8 as, because apparently the a* in 
the submatch can't match 4 as. This makes no sense.

-- 
-- 
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.

Regex matching composite numbers no longer works with NFA engine

[Urtica dioica]

The regex in question became somewhat famous after the VimCast at 
http://vimcasts.org/episodes/vimgolf-prime-numbers/

Here's the setup:

CTab1EscqqC-AYpq540@q

From here, the following command is used to remove lines with a composite 
number ot tabs:

:g/\v^(TabTab+)\1+/dCR

On Vim 7.4.91, this regex uses the NFA engine, and fails to match the correct 
number of tabs. When manually switching engines by prepending \%#=1 to the 
regex, it works correctly.

By removing the  at the end of the regex, like this:

\v^(\t\t+)\1+

and searching with 'hlsearch' on, you can see how many tabs are matched. The 
old engine correctly matches the highest composite number of tabs possible in 
each line. The NFA engine matches a number of tabs equal to the highest number 
in: 4, 6, 10, 18, 34, 66, 130, 258, 514. What the pattern is, I don't know.

-- 
-- 
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.

Key after Press ENTER prompt recorded double

[Urtica dioica]

Open a blank Vim (I'm using 7.4.52), and type this:

3graqqY:s/a/b/g|s/b/c/gCRpq@q

(Since there are 3 as, and the 'report' default is 2, both :s commands report 
the number of changes, which triggers a Press ENTER prompt. But the bug applies 
to any Press ENTER prompt.)

When p is run straight after the prompt, it runs once (as it should). In the 
q register however, the p is recorded twice. You can confirm this with 
:display q. When you run @q, p runs both times, as it's recorded in the 
macro.

The same problem exists when recording keystrokes to a file with vim -w.

If you actually hit Enter to dismiss the prompt, that will also be recorded. If 
you put it in a macro, for instance, the extra Enter will run and try to move 
the cursor.

-- 
-- 
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: Key after Press ENTER prompt recorded double

[Urtica dioica]

вторник, 8 октября 2013 г., 11:49:19 UTC-6 пользователь Christian Brabandt 
написал:
 On Di, 08 Okt 2013, Urtica dioica wrote:
 
 
 
  Open a blank Vim (I'm using 7.4.52), and type this:
 
  
 
  3graqqY:s/a/b/g|s/b/c/gCRpq@q
 
  
 
  (Since there are 3 as, and the 'report' default is 2, both :s commands 
  report the number of changes, which triggers a Press ENTER prompt. But the 
  bug applies to any Press ENTER prompt.)
 
  
 
  When p is run straight after the prompt, it runs once (as it should). In 
  the q register however, the p is recorded twice. You can confirm this 
  with :display q. When you run @q, p runs both times, as it's recorded 
  in the macro.
 
  
 
  The same problem exists when recording keystrokes to a file with vim -w.
 
  
 
  If you actually hit Enter to dismiss the prompt, that will also be 
  recorded. If you put it in a macro, for instance, the extra Enter will run 
  and try to move the cursor.
 
 
 
 Hmm, the problem is, that wait_return pushes the entered character back
 
 into the input queue. 
 
 
 
 I think, this patches fixes it.
 
 
 
 diff --git a/src/message.c b/src/message.c
 
 --- a/src/message.c
 
 +++ b/src/message.c
 
 @@ -887,6 +887,7 @@
 
  intoldState;
 
  inttmpState;
 
  inthad_got_int;
 
 +inthad_Recording = Recording;
 
  
 
  if (redraw == TRUE)
 
 must_redraw = CLEAR;
 
 @@ -957,11 +958,16 @@
 
  * typeahead buffer. */
 
 ++no_mapping;
 
 ++allow_keys;
 
 +   /* temporarily disable Recording. If Recording is active, the char
 
 +* will be recorded later, since the character will be added to 
 the
 
 +* typebuf after the loop */
 
 +   Recording = FALSE;
 
 c = safe_vgetc();
 
 if (had_got_int  !global_busy)
 
 got_int = FALSE;
 
 --no_mapping;
 
 --allow_keys;
 
 +   Recording = had_Recording;
 
  
 
  #ifdef FEAT_CLIPBOARD
 
 /* Strange way to allow copying (yanking) a modeless selection at
 
 
 
 
 
 regards,
 
 Christian
 
 -- 
 
 Das Zuhause ist keineswegs der einzige zivilisierte Ort in einer
 
 abenteuerlichen Welt, sondern der einzige unzivilisierte in einer Welt
 
 der Zw�nge und Pflichten.
 
   -- Gilbert Keith Chesterton

I tried your patch. It seems to stop duplication when recording a macro with q, 
but not when recording keystrokes to a file with vim -w.

-- 
-- 
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: Key after Press ENTER prompt recorded double

[Urtica dioica]

On Tuesday, October 8, 2013 1:13:42 PM UTC-6, Christian Brabandt wrote:
 Try this updated patch.

Cool. That covers all the problems I'm aware of. Just hope there's not a third 
stroke-recording mechanism I haven't thought of. ;)

-- 
-- 
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.