Age | Commit message (Collapse) | Author |
|
Changes to search commands ('/', '?', 'n' and 'N'):
- Rewrite to be smaller and (possibly) clearer.
- Issue a warning when a repeat search is requested without a
previous search having been made.
Vim and BusyBox vi support a repetition count for searches though
the original vi doesn't. If the count exceeds the number of
occurrences of the search string the search may loop through the
file multiple times.
function old new delta
.rodata 105135 105119 -16
do_cmd 4898 4860 -38
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-54) Total: -54 bytes
Signed-off-by; Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Since commit 70ee23399 (vi: code shrink) the ':set' command is
unable to process multiple options on a line. Fix this by
temporarily null-terminating each option.
Change the default setting for all options to off to match vim.
Actually, 'flash' isn't an option in vim, only traditional vi,
where it's on by default. In vim the corresponding option is
'visualbell' which defaults to off. POSIX doesn't have either
of these.
Allow the abbreviation 'ts' for the 'tabstop' option.
Issue an error message if:
- an option is not implemented
- an option that takes a value has no '=' or has a 'no' prefix
- a boolean option has a '='
function old new delta
colon 2944 3003 +59
.rodata 103171 103189 +18
vi_main 274 270 -4
setops 73 - -73
------------------------------------------------------------------------------
(add/remove: 0/1 grow/shrink: 2/1 up/down: 77/-77) Total: 0 bytes
v2: Try harder to detect invalid options. Thanks to Peter D for pointing
this out.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Since commit 25d259264 (vi: make buffer handling more vi-like)
find_range() can return early when an invalid movement is
specified.
The call to find_range() in the code that handles shift commands
('<' and '>') doesn't check for this condition. Previously this
only resulted in the current line being shifted but it can now
result in a segfault.
Check for an invalid movement and notify the user without taking
any further action.
function old new delta
do_cmd 4890 4898 +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>
|
|
- In the '+' and '-' commands the call to dot_skip_over_ws() is
only needed for the final line processed so it can be moved out
of the while loop.
- Marking sync_cursor() NOINLINE doesn't seem to offer the same
advantages it did in 2009 (commit adf922ec2).
function old new delta
refresh 694 974 +280
do_cmd 4900 4887 -13
sync_cursor 336 - -336
------------------------------------------------------------------------------
(add/remove: 0/1 grow/shrink: 1/1 up/down: 280/-349) Total: -69 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Movement by paragraph doesn't always involve whole lines. If the
cursor is positioned in the middle of a line deleting to either end
of the paragraph will result in one partial line and zero or more
full lines.
Adjust the end of ranges delimited by paragraph movement to more
closely match what vi does.
function old new delta
find_range 467 518 +51
at_eof - 49 +49
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 1/0 up/down: 100/0) Total: 100 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
When moving by paragraph ('{' and '}'):
- Treat multiple empty lines as a single paragraph separator.
- When no paragraph separator is found move to the start or end of
the file depending on the direction of motion.
function old new delta
do_cmd 4821 4900 +79
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 79/0) Total: 79 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
The paragraph motion commands '{' and '}' should accept a count.
function old new delta
do_cmd 5054 5071 +17
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 17/0) Total: 17 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
The motion that determines the range of a change, delete, yank
or shift operation can have its own count. Thus the commands
'5dd' and 'd5d' are equivalent: both delete 5 lines.
When the command itself also has a count the two values are
multiplied. Thus the command '2d3w' deletes 6 words and '2D3G'
deletes from the current line to line 6.
(When dealing with structured data it might make sense to think in
units of 3 words so '2d3w' is deleting 2 such units. It doesn't
seem quite as sensible to express 'delete from current line to line 6'
as '2D3G' but vi permits it.)
function old new delta
get_motion_char - 68 +68
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 0/0 up/down: 68/0) Total: 68 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Add 'F', 'T' and '|' as commands that can be used to specify a
range for change/delete/yank operations.
function old new delta
.rodata 105129 105135 +6
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 6/0) Total: 6 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
- Use a common routine to handle all commands to search for a
character in a line.
- When searching for the nth occurrence of a character don't move
the cursor if fewer than n occurrences are present.
- Add support for the 'T' command, search backwards for character
after next occurrence of given character.
function old new delta
do_cmd 4861 4805 -56
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-56) Total: -56 bytes
v2: Add parentheses to avoid searches continuing past end of line.
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
When the 'j'/'k' commands or up/down arrow keys are used to move
the cursor vertically 'vi' remembers the original cursor column
and positions the cursor there if possible. Also, if the '$'
command has been used to position the cursor at the end of a line
vertical movements keep the cursor at the end of the line.
Make BusyBox 'vi' do the same.
function old new delta
refresh 674 694 +20
do_cmd 4853 4861 +8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 28/0) Total: 28 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
The 'G' command with no target (meaning 'go to last line') should
position the cursor on the first visible character of the line, as
it already does in other cases.
The 'M' command should position the cursor on the first visible
character (as 'H' and 'L' already do).
function old new delta
do_cmd 4842 4853 +11
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 11/0) Total: 11 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
If the name of the file being written doesn't match the current
filename and the output file already exists vi should issue a
warning and not overwrite the file.
Because the test only compares the file names it's somewhat over-
protective. If the current file name is 'my_text' and the user tries
to save to './my_text' they'll be prevented from doing so.
function old new delta
colon 3092 3151 +59
.rodata 105118 105146 +28
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/0 up/down: 87/0) Total: 87 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Vi places text affected by change/delete/yank operations into a
buffer. The contents of such buffers can be restored with the put
commands, 'p' or 'P'. These behave differently depending on whether
the buffer contains whole lines or partial lines. For whole lines
the text is copied into the file on the line before (P) or after
(p) the current line. For partial lines the text is copied before
or after the current cursor position.
Whether an operation results in whole or partial lines depends on
the command used.
BusyBox vi treats any buffer with a newline as though it contained
whole lines. This is incorrect. Deleting multiple words across
a line boundary results in a buffer with a newline but not having
whole lines.
Rework how buffers are handled to behave more like vi.
function old new delta
static.text_yank 79 99 +20
colon 3092 3097 +5
edit_file 885 887 +2
yank_delete 127 112 -15
.rodata 105139 105101 -38
find_range 514 467 -47
do_cmd 5088 4842 -246
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/4 up/down: 27/-346) Total: -319 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
I was puzzled by code in find_range() which handles forward word
movement. It included a test to see if we're at the start of a
word. Since these are forward word movements surely we'd expect to
be at the start of a word? In fact, the test was intended to fix a
problem with changes to the last word in a file, as discussed in the
thread starting here:
http://lists.busybox.net/pipermail/busybox/2004-January/044552.html
The code can be simplified by testing directly for end of file instead
of indirectly for not being at the start of a word. Since trailing
whitespace is now handled in do_cmd() the code to back up off a newline
is no longer required.
function old new delta
find_range 619 514 -105
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-105) Total: -105 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Commit 4b49422a0 (vi: fix changes to word at end of line. Closes
11796) fixed a problem where an operation on a word at the end of
a line followed by a line starting with whitespace incorrectly
joined the lines. However it also broke the case where operating
on multiple words across a line boundary *should* join the lines.
Fix this by detecting when trailing whitepace in a word operation
includes a newline. Whitespace beyond the newline is excluded
from consideration.
function old new delta
do_cmd 5083 5088 +5
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 5/0) Total: 5 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
setops 85 73 -12
colon 2965 2915 -50
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-62) Total: -62 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Fixes bug where commands after the first noXXX command are ignored.
e.g. :set noic tabstop=4
While at it, stop recognizing "notabstop=NNN".
function old new delta
colon 2990 2965 -25
Signed-off-by: Alison Winters <alisonatwork@outlook.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
fputs_stdout - 12 +12
zxc_vm_process 7237 7230 -7
yes_main 85 78 -7
write_block 380 373 -7
wrapf 305 298 -7
strings_main 437 430 -7
show_bridge 353 346 -7
rev_main 384 377 -7
put_prompt_custom 58 51 -7
put_cur_glyph_and_inc_cursor 168 161 -7
print_numbered_lines 152 145 -7
print_named_ascii 130 123 -7
print_name 135 128 -7
print_login_issue 386 379 -7
print_ascii 208 201 -7
powertop_main 1249 1242 -7
od_main 1789 1782 -7
logread_main 518 511 -7
head_main 804 797 -7
display_process_list 1319 1312 -7
cut_main 1002 995 -7
bb_dump_dump 1550 1543 -7
bb_ask_noecho 393 386 -7
baseNUM_main 702 695 -7
expand_main 755 745 -10
dumpleases_main 497 487 -10
write1 12 - -12
putcsi 37 23 -14
print_login_prompt 55 41 -14
paste_main 525 511 -14
cat_main 440 426 -14
print_it 245 230 -15
print_addrinfo 1188 1171 -17
print_rule 770 750 -20
print_linkinfo 842 822 -20
httpd_main 791 771 -20
------------------------------------------------------------------------------
(add/remove: 1/1 grow/shrink: 0/34 up/down: 12/-341) Total: -329 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Selection of ranges for change/delete/yank by forward character
motion commands (SPACE or 'l') was incorrect. The range was
always one character whereas vi allows the size of the range to
be specified.
Fix this by executing the motion command the required number of times.
There is a complication when the range is at the end of a line. We need
to distinguish between a range which excludes the last character and
one which includes it. This requires comparing the actual range with
that expected from the command count. (With the additional quirk that
a command count of zero is equivalent to a command count of one.)
function old new delta
find_range 587 619 +32
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/0 up/down: 32/0) Total: 32 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
packed_usage 33620 33665 +45
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Handling of string searches in colon commands (e.g ':/pat1/,/pat2/cmd')
differ from standard vi:
- As reported in bug 10321 such searches can't be repeated using the
'n' command. This is because the last search pattern isn't updated.
- The search also can't be repeated using the command '://' because
an empty search pattern doesn't imply the use of the last search
pattern.
- Such searches should start on the line after the current line,
otherwise '://' never moves to the next occurrence of the pattern.
This can also affect other cases where line ranges are specified
using search patterns.
Fix these various issues.
function old new delta
get_one_address 325 342 +17
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Back in 2007, commit 0c97c9d43707 ("'simple' error message functions by
Loic Grenie") introduced bb_simple_perror_msg() to allow for a lower
overhead call to bb_perror_msg() when only a string was being printed
with no parameters. This saves space for some CPU architectures because
it avoids the overhead of a call to a variadic function. However there
has never been a simple version of bb_error_msg(), and since 2007 many
new calls to bb_perror_msg() have been added that only take a single
parameter and so could have been using bb_simple_perror_message().
This changeset introduces 'simple' versions of bb_info_msg(),
bb_error_msg(), bb_error_msg_and_die(), bb_herror_msg() and
bb_herror_msg_and_die(), and replaces all calls that only take a
single parameter, or use something like ("%s", arg), with calls to the
corresponding 'simple' version.
Since it is likely that single parameter calls to the variadic functions
may be accidentally reintroduced in the future a new debugging config
option WARN_SIMPLE_MSG has been introduced. This uses some macro magic
which will cause any such calls to generate a warning, but this is
turned off by default to avoid use of the unpleasant macros in normal
circumstances.
This is a large changeset due to the number of calls that have been
replaced. The only files that contain changes other than simple
substitution of function calls are libbb.h, libbb/herror_msg.c,
libbb/verror_msg.c and libbb/xfuncs_printf.c. In miscutils/devfsd.c,
networking/udhcp/common.h and util-linux/mdev.c additonal macros have
been added for logging so that single parameter and multiple parameter
logging variants exist.
The amount of space saved varies considerably by architecture, and was
found to be as follows (for 'defconfig' using GCC 7.4):
Arm: -92 bytes
MIPS: -52 bytes
PPC: -1836 bytes
x86_64: -938 bytes
Note that for the MIPS architecture only an exception had to be made
disabling the 'simple' calls for 'udhcp' (in networking/udhcp/common.h)
because it made these files larger on MIPS.
Signed-off-by: James Byrne <james.byrne@origamienergy.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
colon 2852 2846 -6
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
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>
|
|
function old new delta
vi_main 273 272 -1
colon 2853 2852 -1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-2) Total: -2 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
new_screen 84 75 -9
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>
|
|
function old new delta
vi_main 272 273 +1
colon 2852 2853 +1
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
modifying_cmds 17 22 +5
get_one_char 103 98 -5
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/1 up/down: 5/-5) Total: 0 bytes
text data bss dec hex filename
982121 485 7296 989902 f1ace busybox_old
982094 485 7296 989875 f1ab3 busybox_unstripped
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
get_input_line 172 175 +3
char_insert 444 447 +3
rawmode 36 24 -12
edit_file 644 626 -18
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 2/2 up/down: 6/-30) Total: -24 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
get_one_char 108 103 -5
edit_file 651 644 -7
do_cmd 4696 4688 -8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-20) Total: -20 bytes
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>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
function old new delta
tstp_handler 64 71 +7
text_yank 54 56 +2
vi_main 280 272 -8
do_cmd 4705 4696 -9
colon 2861 2852 -9
cont_handler 66 - -66
------------------------------------------------------------------------------
(add/remove: 0/1 grow/shrink: 2/3 up/down: 9/-92) Total: -83 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
|
|
While at it, sanitized comment style, deleted wrong ones, renamed signal
handlers to <sig>_handler(), slightly optimized "cursor home+clear screen".
function old new delta
cont_handler - 66 +66
tstp_handler - 64 +64
winch_handler - 60 +60
int_handler - 32 +32
edit_file 648 651 +3
redraw 52 43 -9
catch_sig 32 - -32
winch_sig 60 - -60
suspend_sig 64 - -64
cont_sig 66 - -66
------------------------------------------------------------------------------
(add/remove: 4/4 grow/shrink: 1/1 up/down: 225/-231) Total: -6 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>
|
|
function old new delta
yank_delete 98 99 +1
what_reg 34 33 -1
text_yank 56 54 -2
end_cmd_q 17 14 -3
do_cmd 4718 4705 -13
colon 2875 2861 -14
edit_file 668 648 -20
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 1/6 up/down: 1/-53) Total: -52 bytes
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>
|
|
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>
|