The 'G' command was omitted from the list of commands that change or
delete whole lines. Add it in the appropriate places so the 'dG',
'cG' and 'yG' commands work, including in cases where an explicit
line number has been supplied.
function old new delta
find_range 534 596 +62
.rodata 175166 175167 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 63/0) Total: 63 bytes
Reported-by: David Kelly <david.kelly@liberica.ch>
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
As reported in bug 11796 BusyBox vi incorrectly handles changes
to a word at the end of a line. If the following line starts
with whitespace changing or deleting the last word of a line
with the 'cw' or 'dw' commands causes the lines to be joined.
This happens because the range for the change returned by
find_range() covers all whitespace after the word, including
newlines. The problem can be fixed by setting 'ml' to zero
to indicate to yank_delete() that processing should stop at
the end of the current line.
However, this results in a new problem. 'dw' correctly deletes
all whitespace following the word but so does 'cw', which should
preserve the trailing whitespace. To fix this the code to omit
whitespace from the change is modified to include all whitespace
not just blanks.
function old new delta
do_cmd 5034 5069 +35
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 35/0) Total: 35 bytes
Reported-by: David Kelly <david.kelly@liberica.ch>
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If vi is built with FEATURE_VI_USE_SIGNALS disabled and
FEATURE_VI_WIN_RESIZE enabled new_screen() is used without a
declaration. Move the function to avoid this.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This is the last use of "vsprintf" in busybox:
function old new delta
status_line_bold 72 77 +5
status_line 40 45 +5
vsprintf 23 - -23
------------------------------------------------------------------------------
(add/remove: 0/2 grow/shrink: 2/0 up/down: 10/-23) Total: -13 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
On platforms that don't support SIGWINCH vi can be configured
with FEATURE_VI_USE_SIGNALS disabled and FEATURE_VI_WIN_RESIZE
enabled. This allows the user to force an update with ^L when
the screen is resized.
However, because the SIGWINCH handler hasn't run the virtual
screen buffer won't have been updated and the display becomes
corrupted. Fix this by calling new_screen() if necessary.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Commit bb983f30e (vi: fix faulty undo after autoinsert) has a
number of problems:
- The commit message refers to 'autoinsert' when it really means
'autoindent'.
- The indentation of undo_push_insert() was incorrect.
- Most seriously the commit only fixed the problem for cases where
the indentation was exactly one character. This is because undo_push()
only allows single characters to be queued for UNDO_INS_QUEUED.
Lifting this restriction allows the example given in the previous
commit message (with a three character indent) to work.
function old new delta
undo_push 406 435 +29
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 29/0) Total: 29 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Currently if the 'r' command is followed by a carriage return a
literal CR replaces the current character.
Fix this so that:
- a new line is inserted
- the autoindent setting is respected
- the cursor is placed at the start of the new line
function old new delta
do_cmd 5052 5060 +8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 8/0) Total: 8 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Enable autoinsert and enter the following with an indent of three
spaces:
line 1
line 2
Using 'u' to undo the last insert results in:
line1e 2
The insertion of the indent hasn't been properly recorded.
Since recording insertions is a common operation add a convenience
function, undo_push_insert(), to handle this and use it to record
the autoindent correctly.
function old new delta
undo_push_insert - 36 +36
string_insert 133 129 -4
char_insert 518 473 -45
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 0/2 up/down: 36/-49) Total: -13 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Michał Berger has reported two issues:
- Repeatedly deleting and undoing the deletion of the last line
results in characters being lost from the end of the line.
- Deleting the bottom line twice then attempting to undo each of
these deletions results in a segfault.
The problem seems to be an incorrect test for whether the text buffer
is empty.
Reported-by: Michał Berger <michallinuxstuff@gmail.com>
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
If busybox is compiled with FEATURE_VI_REGEX_SEARCH enabled, command
":s/x/y/" searches not only in the current line, but continues search
after it. This makes range searches (":1,3s/x/y/") work incorrect. For
example file "./test":
1
2
3
$ vi ./test
:1,2s/3/e/
gives us:
1
2
e
function old new delta
char_search 213 241 +28
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
At worst show_status_line() might be called needlessly when the
user presses ^L/^R, but I don't think we'll get many complaints
about that.
function old new delta
do_cmd 4592 4558 -34
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-34) Total: -34 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This is the behaviour observed with standard vim and busybox vi of at
least 1.22.1. It was changed with commit "32afd3a vi: some
simplifications" which happened before 1.23.0.
Mistyping filename on command line happens fairly often and it's better
we restore the old behaviour to avoid a few unnecessary flash writes and
sometimes efforts of debugging bugs caused by those unneeded stray
files.
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Along with it, there are other changes
- Check for uppercase X is removed as the expression will be always false and
:X itself is another totally different command in standard vim
- The status line will show number of written lines instead of lines requested
by the colon command. This is also how the standard vim is doing, though
the difference is that '!' has to be explicitly specified in vim to allow
partial writes
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Redundant help texts (one which only repeats the description)
are deleted.
Descriptions and help texts are trimmed.
Some config options are moved, even across menus.
No config option _names_ are changed.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The '' command in vi doesn't currently work because after the first
apostrophe is read, the next character is converted to an integer
between 0 and 25 inclusive (for indexing the array of marks). The
comparison of the converted character with an apostrophe therefore never
succeeds, meaning that '' doesn't do anything.
Based on the patch by Francis Rounds <francis.rounds@4bridgeworks.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The result of looking at "grep -F -B2 '*fill*' busybox_unstripped.map"
text data bss dec hex filename
829901 4086 1904 835891 cc133 busybox_before
829665 4086 1904 835655 cc047 busybox
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Currently basic undo functionality with the 'u' key depends on
FEATURE_VI_YANKMARK. These two features are separate, so we can remove this
dependency.
Signed-off-by: Andrew Fuller <abf@google.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
