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
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
> 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
---
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
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
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
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
---
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
---
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.
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,
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
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
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
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.
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
\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
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
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
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
вторник, 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
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
21 matches
Mail list logo
