It is a design goal of extmarks that they allow precise tracking
of changes across undo/redo, including restore the exact positions
after a do/undo or undo/redo cycle. However this behavior is not useful
for all usecases. Many plugins won't keep marks around for long after
text changes, but uses them more like a cache until some external source
(like LSP semantic highlights) has fully updated to changed text and
then will explicitly readjust/replace extmarks as needed.
Add a "undo_restore" flag which is true by default (matches existing
behavior) but can be set to false to opt-out of this behavior.
Delete dead u_extmark_set() code.
Previously, 'rightleftcmd' was implemented by having all code which
would affect msg_col or output screen cells be conditional on `cmdmsg_rl`.
This change removes all that and instead implements rightleft as a
mirroring post-processing step.
connection from any channel or stdio will unblock
remote_ui_wait_for_attach. Wait on stdio only if
only —embed specified, if both —embed and
—listen then wait on any channel.
Problem:
`win_get_bordertext_col` returns column < 1 for right or center
aligned text, if its length is more than window width.
Solution:
Return max(resulting_column, 1)
Problem: Wrong color for half of wide character next to pum scrollbar.
Solution: Redraw the screen cell with the right color. (closesvim/vim#9874)
35d8c2010e
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: [security] use-after-free with wildmenu
Solution: properly clean up the wildmenu when exiting
Fix wildchar/wildmenu/pum memory corruption with special wildchar's
Currently, using `wildchar=<Esc>` or `wildchar=<C-\>` can lead to a
memory corruption if using wildmenu+pum, or wrong states if only using
wildmenu. This is due to the code only using one single place inside the
cmdline process loop to perform wild menu clean up (by checking
`end_wildmenu`) but there are other odd situations where the loop could
have exited and we need a post-loop clean up just to be sure. If the
clean up was not done you would have a stale popup menu referring to
invalid memory, or if not using popup menu, incorrect status line (if
`laststatus=0`).
For example, if you hit `<Esc>` two times when it's wildchar, there's a
hard-coded behavior to exit command-line as a failsafe for user, and if
you hit `<C-\><C-\><C-N>` it will also exit command-line, but the clean
up code would not have hit because of specialized `<C-\>` handling.
Fix Ctrl-E / Ctrl-Y to not cancel/accept wildmenu if they are also
used for 'wildchar'/'wildcharm'. Currently they don't behave properly,
and also have potentially memory unsafe behavior as the logic is
currently not accounting for this situation and try to do both.
(Previous patch that addressed this: vim/vim#11677)
Also, correctly document Escape key behavior (double-hit it to escape)
in wildchar docs as it's previously undocumented.
In addition, block known invalid chars to be set in `wildchar` option,
such as Ctrl-C and `<CR>`. This is just to make it clear to the user
they shouldn't be set, and is not required for this bug fix.
closes: vim/vim#133618f4fb007e4
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: A few remaining cmdline completion issues with C-E/Y
Solution: Fix cmdline completion fuzzy/Ctrl-E/Ctrl-Y/options when not
used at the end
Fix cmdline completion fuzzy/Ctrl-E/Ctrl-Y/options when not used at the end
A few places in the cmdline completion code only works properly when the
user hits Tab (or 'wildchar') at the end of the cmdline, even though
it's supposed to work even in the middle of the line.
For fuzzy search, `:e ++ff`, and `:set hl=`, fix completion code to make
sure to use `xp_pattern_len` instead of assuming the entire `xp_pattern`
is the search pattern (since it contains texts after the cursor).
Fix Ctrl-E / Ctrl-Y to not jump to the end when canceling/accepting a
wildmenu completion. Also, make them work even when not using
`set wildoptions+=pum` as there is no drawback to doing so.
(Related issue where this was brought up: vim/vim#13331)
closes: vim/vim#13362209ec90b9b
Cherry-pick ex_getln.c changes from patch 9.0.2035.
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: Cannot accurately get mouse clicking position when clicking on
a TAB or with virtual text.
Solution: Add a "coladd" field to getmousepos() result.
closes: vim/vim#13335f5a94d5165
Problem:
The next command after `silent !{cmd}` or `silent lua print('str')`
prints an empty line before printing a message, because these commands
set `msg_didout = true` despite not printing any messages.
Solution:
Set `msg_didout = true` only if `msg_silent == 0`
Problem: Peeking and flushing output slows down execution.
Solution: Do not update the mode message when global_busy is set. Do not
flush when only peeking for a character. (Ken Takata)
cb574f4154
PROBLEM:
Currently `:echoerr` prints multi-line strings in a single line
as `:echom` does (Note: `:echon` can print multi-line strings well).
This makes stacktrace printed via echoerr difficult to read.
Example code:
try
lua error("lua stacktrace")
catch
echoerr v:exception
endtry
Output:
Error detected while processing a.vim[5]..a.vim:
line 4:
Vim(lua):E5108: Error executing lua [string ":lua"]:1: lua stacktrace^@stack traceback:^@^I[C]: in function 'error'^@^I[string ":lua"]:1: in main chunk
SOLUTION:
Allow echoerr to print multiline messages (e.g., lua exceptions),
because this command is usually used to print stacktraces.
Output after the fix:
Error detected while processing a.vim[5]..a.vim:
line 4:
Vim(lua):E5108: Error executing lua [string ":lua"]:1: lua stacktrace
stack traceback:
[C]: in function 'error'
[string ":lua"]:1: in main chunk
The 'arabicshape' feature of vim is a transformation of unicode text to
make arabic and some related scripts look better at display time. In
particular the content of a cell will be adjusted depending on the
(original) content of the cells just before and after it.
This is implemented by the arabic_shape() function in nvim. Before this
commit, shaping was invoked in four different contexts:
- when rendering buffer text in win_line()
- in line_putchar() for rendering virtual text
- as part of grid_line_puts, used by messages and statuslines and
similar
- as part of draw_cmdline() for drawing the cmdline
This replaces all these with a post-processing step in grid_put_linebuf(),
which has become the entry point for all text rendering after recent
refactors.
An aim of this is to make the handling of multibyte text yet simpler.
One of the main reasons multibyte chars needs to be "parsed" into
codepoint arrays of composing chars is so that these could be inspected
for the purpose of shaping. This can likely be vastly simplified in many
contexts where only the total length (in bytes) and width of composed
char is needed.
This finalizes the long running refactor from the old TUI-focused grid
implementation where text-drawing cursor was not separated from the
visible cursor.
Still, the pattern of setting cursor position together with updating a
line was convenient. Introduce grid_line_cursor_goto() to still allow
this but now being explicit about it.
Only having batched drawing functions makes code involving drawing
a bit longer. But it is better to be explicit, and this highlights
cases where multiple small redraws can be grouped together. This was the
case for most of the changed places (messages, lastline, and :intro)
msg_puts_display was more complex than necessary in nvim, as in
nvim, it no longer talks directly with a terminal.
In particular we don't need to scroll the grid before emiting the last
char. The TUI already takes care of things like that, for terminals
where it matters.
Problem:
Crash from:
set cmdheight=0 redrawdebug=invalid
resize -1
Solution:
Do not invalidate first `p_ch` `msg_grid` rows in `update_screen` when
scrolling the screen down after displaying a message, because they may
be used later for drawing cmdline.
Fixes#22154
Problem: Wrong curswant when clicking on empty line or with vsplits.
Solution: Don't check for ScreenCols[] before the start of the window
and handle empty line properly.
closes: vim/vim#1313203cd697d63
Previously, a screen cell would occupy 28+4=32 bytes per cell
as we always made space for up to MAX_MCO+1 codepoints in a cell.
As an example, even a pretty modest 50*80 screen would consume
50*80*2*32 = 256000, i e a quarter megabyte
With the factor of two due to the TUI side buffer, and even more when
using msg_grid and/or ext_multigrid.
This instead stores a 4-byte union of either:
- a valid UTF-8 sequence up to 4 bytes
- an escape char which is invalid UTF-8 (0xFF) plus a 24-bit index to a
glyph cache
This avoids allocating space for huge composed glyphs _upfront_, while
still keeping rendering such glyphs reasonably fast (1 hash table lookup
+ one plain index lookup). If the same large glyphs are using repeatedly
on the screen, this is still a net reduction of memory/cache
consumption. The only case which really gets worse is if you blast
the screen full with crazy emojis and zalgo text and even this case
only leads to 4 extra bytes per char.
When only <= 4-byte glyphs are used, plus the 4-byte attribute code,
i e 8 bytes in total there is a factor of four reduction of memory use.
Memory which will be quite hot in cache as the screen buffer is scanned
over in win_line() buffer text drawing
A slight complication is that the representation depends on host byte
order. I've tested this manually by compling and running this
in qemu-s390x and it works fine. We might add a qemu based solution
to CI at some point.
The removes the previous restriction that nvim_buf_set_extmark()
could not be used to highlight arbitrary multi-line regions
The problem can be summarized as follows: let's assume an extmark with a
hl_group is placed covering the region (5,0) to (50,0) Now, consider
what happens if nvim needs to redraw a window covering the lines 20-30.
It needs to be able to ask the marktree what extmarks cover this region,
even if they don't begin or end here.
Therefore the marktree needs to be augmented with the information covers
a point, not just what marks begin or end there. To do this, we augment
each node with a field "intersect" which is a set the ids of the
marks which overlap this node, but only if it is not part of the set of
any parent. This ensures the number of nodes that need to be explicitly
marked grows only logarithmically with the total number of explicitly
nodes (and thus the number of of overlapping marks).
Thus we can quickly iterate all marks which overlaps any query position
by looking up what leaf node contains that position. Then we only need
to consider all "start" marks within that leaf node, and the "intersect"
set of that node and all its parents.
Now, and the major source of complexity is that the tree restructuring
operations (to ensure that each node has T-1 <= size <= 2*T-1) also need
to update these sets. If a full inner node is split in two, one of the
new parents might start to completely overlap some ranges and its ids
will need to be moved from its children's sets to its own set.
Similarly, if two undersized nodes gets joined into one, it might no
longer completely overlap some ranges, and now the children which do
needs to have the have the ids in its set instead. And then there are
the pivots! Yes the pivot operations when a child gets moved from one
parent to another.
Problem:
* The guessed botline might be smaller than the actual botline e.g. when
there are folds and the user is typing in insert mode. This may result
in incorrect treesitter highlights for injections.
* botline can be larger than the last line number of the buffer, which
results in errors when placing extmarks.
Solution:
* Take a more conservative approximation. I am not sure if it is
sufficient to guarantee correctness, but it seems to be good enough
for the case mentioned above.
* Clamp it to the last line number.
Co-authored-by: Lewis Russell <me@lewisr.dev>
Problem: Wrong cursor position with virtual text before double-width
char at window edge.
Solution: Check for double-width char before adding virtual text size.
closes: vim/vim#12977ac2d8815ae
Problem: Wrong cursor position with virtual text before a whitespace
character and 'linebreak'.
Solution: Always set "col_adj" to "size - 1" and apply 'linebreak' after
adding the size of 'breakindent' and 'showbreak'.
closes: vim/vim#129566e55e85f92
N/A patches:
vim-patch:9.0.1826: keytrans() doesn't translate recorded key typed in a GUI
Problem: Multiline regex with Visual selection fails when Visual
selection contains virtual text after last char.
Solution: Only include virtual text after last char when getting full
line length.
closes: vim/vim#12908e3daa06be1
Problem: Cursor position still wrong with 'showbreak' and virtual text
after last character or 'listchars' "eol".
Solution: Remove unnecessary w_wcol adjustment in curs_columns(). Also
fix first char of virtual text not shown at the start of a screen
line.
closes: vim/vim#12478closes: vim/vim#12532closes: vim/vim#129046a3897232a
Problem: Normal mode "gM", "gj", "gk" commands behave incorrectly with
virtual text.
Solution: Use linetabsize() instead of linetabsize_str().
closes: vim/vim#12909d809c0a903
Problem: Now way to show text at the bottom part of floating window
border (a.k.a. "footer").
Solution: Allows `footer` and `footer_pos` config fields similar to
`title` and `title_pos`.
Most of the messy things when changing a non-current buffer is
not about the buffer, it is about windows. In particular, it is about
`curwin`.
When editing a non-current buffer which is displayed in some other
window in the current tabpage, one such window will be "borrowed" as the
curwin. But this means if two or more non-current windows displayed the buffers,
one of them will be treated differenty. this is not desirable.
In particular, with nvim_buf_set_text, cursor _column_ position was only
corrected for one single window. Two new tests are added: the test
with just one non-current window passes, but the one with two didn't.
Two corresponding such tests were also added for nvim_buf_set_lines.
This already worked correctly on master, but make sure this is
well-tested for future refactors.
Also, nvim_create_buf no longer invokes autocmds just because you happened
to use `scratch=true`. No option value was changed, therefore OptionSet
must not be fired.
Problem: wrong cursor position with 'showbreak' and lcs-eol
Solution: Add size of 'showbreak' before when 'listchars' "eol" is used.
Also fix wrong cursor position with wrapping virtual text on
empty line and 'showbreak'.
closes: vim/vim#128911193951beb
Problem: Wrong display with wrapping virtual text or unprintable chars,
'showbreak' and 'smoothscroll'.
Solution: Don't skip cells taken by 'showbreak' in screen lines before
"w_skipcol". Combined "n_skip" and "skip_cells".
closes: vim/vim#12597b557f48982
Problem: Using freed memory when 'tagfunc' wipes out buffer that holds
'complete'.
Solution: Make a copy of the option. Make sure cursor position is valid.
0ff01835a4
Cherry-pick a cmdwin change from patch 9.0.0500.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Using setbufvar() may change the window title.
Solution: Do not redraw when creating the autocommand window. (closesvim/vim#9613)
dff97e65eb
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Missing test coverage for blockwise Visual highlight with
virtual that starts with a double-width char.
Solution: Add a new virtual text to the test. Some other small fixes.
closes: vim/vim#12835fc3058495d
Problem: Wrong cursor position when clicking after concealed text
with 'virtualedit'.
Solution: Store virtual columns in ScreenCols[] instead of text
columns, and always use coladvance() when clicking.
This also fixes incorrect curswant when clicking on a TAB, so now
Test_normal_click_on_ctrl_char() asserts the same results as the ones
before patch 9.0.0048.
closes: vim/vim#12808e500ae8e29
Remove the mouse_adjust_click() function.
There is a difference in behavior with the old mouse_adjust_click()
approach: when clicking on the character immediately after concealed
text that is completely hidden, cursor is put on the clicked character
rather than at the start of the concealed text. The new behavior is
better, but it causes unnecessary scrolling in a functional test (which
is an existing issue unrelated to these patches), so adjust the test.
Now fully merged:
vim-patch:9.0.0177: cursor position wrong with 'virtualedit' and mouse click
Problem: blockwise Visual highlight not working with virtual text
Solution: Reset the correct variable at the end of virtual selection and
Check for double-width char inside virtual text.
closes: vim/vim#126066e940d9a1d
Need to remove area_active and use wlv.fromcol and wlv.tocol directly.
Problem: A double-width char in a floating window causes an extra
space to be drawn to the left of its boundary.
Solution: Only reset skipstart at the first column.
Fix#24775
Problem: incorrect heights in win_size_restore()
Solution: avoid restoring incorrect heights in win_size_restore()
876f5fb570
I already merged this prior, so just replace the new test with the old one,
but add a test case for the global statusline.
Problem: Cannot break undo by setting 'undolevels' to itself in
'inccommand' preview callback.
Solution: Don't set an invalid 'undolevels' value.
Co-authored-by: Michael Henry <drmikehenry@drmikehenry.com>
Problem: 'inccommand' doesn't restore 'undolevels' properly for a
buffer shown in multiple windows.
Solution: Don't save information of a buffer twice.
Currently it only skips if `Rows` changed, but it's possible for the height of
the usable area for windows to change (e.g: via `&ch`, `&stal` or `&ls`), which
can cause the value of `&cmdheight` to change when the sizes are restored.
This is a Vim bug, so I've submitted a PR there too. No telling when it'll be
merged though, given the current lack of activity there.
`ROWS_AVAIL` is convenient here, but also subtracts the `global_stl_height()`.
Not ideal, as we also care about the height of the last statusline for other
values of `&ls`. Meh.
Introduce `last_stl_height` for getting the height of the last statusline and
use it in `win_size_save/restore` and `last_status` (means
`last_status_rec`'s `statusline` argument will now be true if `&ls` is 3,
but that does not change the behaviour).
Also corrects the logic in `comp_col` to not assume there's a last statusline
if `&ls` is 1 and the last window is floating.
Problem:
The cmdpreview saved undo nodes on cmdpreview_prepare() from ex_getln.c may
become invalid (free) if the preview function makes undo operations, causing
heap-use-after-free errors.
Solution:
Save the buffer undo list on cmdpreview_prepare)_ and start a new empty one. On
cmdpreview_restore_state(), undo all the entries in the new undo list and
restore the original one. With this approach, the preview function will be
allowed to undo only its own changes.
Fix#20036Fix#20248
Problem: Cannot drag a vertical separator to the right of a window
whose 'statuscolumn' is wider than itself.
Solution: Never treat a click on a vertical separator as a click on
'statuscolumn'.
Problem: Cursor is not after inline virtual text with left gravity
when inserting after the end of the line.
Solution: Add width of inline virtual text with left gravity to cursor
virtcol in Insert mode even if on a NUL.
Problem:
Sometimes, when nvim sends the `win_viewport` event, for example when scrolling
with visible folds on the screen, it reports the `scroll_delta` value one batch
into "future". So when the client application is trying to show the new viewport
it's not yet updated, resulting in temporary corruption / screen flickering.
For more details see #23609, and starting from [this comment](
https://github.com/neovide/neovide/pull/1790#issuecomment-1518697747) in
https://github.com/neovide/neovide/pull/1790,, where the issue was first
detected. Note that some of the conclusions in those are not fully accurate, but
the general observations are.
Solution:
When there are pending updates to a Window, delay the `win_viewport` UI event
until the updates are sent. This ensures that there's no flush between sending
the viewport and updating of the lines corresponding to the new viewport.
Document the existing viewport behaviour (for cases where there are no
extra flushes), give a hint about how applications can deal with the slightly
surprising behaviour of the viewport event being sent after the updates.
Fixes https://github.com/neovim/neovim/issues/23609
Redrawing of 'statusline' and 'winbar' are actually already inhibited by
RedawingDisabled in Ex mode.
In Vim there is a check for `msg_scrolled == 0` (which is false in Ex
mode) since Vim doesn't have msgsep. Add a `!exmode_active` check here
in Nvim instead.
Problem: Line pointer becomes invalid when using spell checking.
Solution: Call ml_get() at the right places. (Luuk van Baal, closesvim/vim#12456)
e84c773d42
Problem: Incsearch not triggered when pasting clipboard register on the
command line.
Solution: Also set "literally" when using a clipboard register. (Ken Takata,
closesvim/vim#12460)
9cf6ab1332
Co-authored-by: K.Takata <kentkt@csc.jp>
Problem: SpellCap highlight not always updated when needed.
Solution: Handle updating line below closed fold and other situations where
only part of the window is redrawn. (Luuk van Baal, closesvim/vim#12428,
closesvim/vim#12420)
2ac6497f0e
fixes#23734
Get rid of the weird attr_pri dance which always seemed like a kludge:
if (!attr_pri) {
wlv.char_attr = hl_combine_attr(wlv.char_attr, extmark_attr);
} else {
wlv.char_attr = hl_combine_attr(extmark_attr, wlv.char_attr);
}
Instead combine extmark attrs with (old-skool) syntax attrs in a consistent way and then combine that with attr_pri and the rest in an _unified_ code path
fixes#23722
Co-authored-by: luukvbaal <luukvbaal@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem: Bad redrawing with spell checking, using "C" and "$" in 'cpo'.
Solution: Do not redraw the next line when "$" is in 'cpo'. (closesvim/vim#11285)
f3ef026c98
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: With spell checking, deleting a full stop at the end of a line
does not update SpellCap at the start of the next line.
Solution: Update the next line when characters have been deleted. Also when
using undo.
26f09ea54b
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: After exiting Insert mode spelling is not checked in the next
line.
Solution: When spelling is enabled redraw the next line after exiting Insert
mode in case the spell highlight needs updating.
ee09fcc9b6
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Spell checking for capital not working with trailing space.
Solution: Do not calculate cap_col at the end of the line. (Christian
Brabandt, closesvim/vim#10870, issue vim/vim#10838)
afa23d1b99
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: In diff mode virtual text is highlighted incorrectly. (Rick Howe)
Solution: Do not use diff attributes for virtual text. (closesvim/vim#11714)
d097af7779
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: 'cursorline' causes virtual text highlight to continue.
Solution: Save and restore line_attr. (closesvim/vim#11588)
6ac16f0c0f
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: With 'nowrap' virtual text "after" does not scroll left.
Solution: Skip part of the virtual text that is left of the window.
(closesvim/vim#11320) Fix going beyond the last column of the window.
cd105417a5
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Cursor in wrong position when inserting after virtual text. (Ben
Jackson)
Solution: Put the cursor after the virtual text, where the text will be
inserted. (closesvim/vim#10914)
28c9f89571
Co-authored-by: Bram Moolenaar <Bram@vim.org>
vim-patch:9.0.0193: search and match highlgith interfere with virtual text
Problem: Search and match highlgith interfere with virtual text highlight.
(Ben Jackson)
Solution: Check for match highlight after text properties. Reset and
restore search highlight when showing virtual text.
(closesvim/vim#10892)
e38fc86180
vim-patch:9.0.0452: Visual highlighting extends into virtual text prop
Problem: Visual highlighting extends into virtual text prop.
Solution: Do not highlight what isn't actually selected. Fix ordering of
stored text props.
6eda17d881
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Extra space after virtual text when 'linebreak' is set.
Solution: Do not count virtual text when getting linebreak value.
(closesvim/vim#10884)
52de3a8d39
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Cursor position wrong with virtual text before Tab.
Solution: Use the byte length, not the cell with, to compare the column.
Correct tab size after text prop. (closesvim/vim#10866)
e428fa04a7
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Cursor position wrong with wrapping virtual text in empty line.
Solution: Adjust handling of an empty line. (closesvim/vim#10875)
49a90792d9
Co-authored-by: Bram Moolenaar <Bram@vim.org>
This also fixes insert cursor position around virtual text
vim-patch:9.0.0132: multi-byte characters in virtual text not handled correctly
Problem: Multi-byte characters in virtual text not handled correctly.
Solution: Count screen cells instead of bytes.
09ff4b54fb
vim-patch9.0.0121: cannot put virtual text after or below a line
Problem: Cannot put virtual text after or below a line.
Solution: Add "text_align" and "text_wrap" arguments.
b7963df98f
This only patches the fix, not the whole thing.
vim-patch:9.0.0067: cannot show virtual text
Problem: Cannot show virtual text.
Solution: Initial changes for virtual text support, using text properties.
7f9969c559
vim-patch:9.0.0116: virtual text not displayed if 'signcolumn' is "yes"
Problem: Virtual text not displayed if 'signcolumn' is "yes".
Solution: Set c_extra and c_final to NUL.
711483cd13
Co-authored-by: bfredl <bjorn.linse@gmail.com>
`nvim_(get|set)_option_value` pick the current buffer / window by default for buffer-local/window-local (but not global-local) options. So specifying `buf = 0` or `win = 0` in opts is unnecessary for those options. This PR removes those to reduce code clutter.
Problem: Multibyte characters may be wrapped at the end of a line
when 'statuscolumn' and 'spell' are set.
Solution: Update line pointerdiff "v" before fetching the line pointer
after evaluating 'statuscolumn'.
Revert the change to do_cmdline_cmd() from #5226.
This function is used in many places, so making it different from Vim
leads to small differences from Vim in the behavior of some functions
like execute() and assert_fails(). If DOCMD_VERBOSE really needs to be
removed somewhere, a do_cmdline() call without DOCMD_VERBOSE is also
shorter than a do_cmdline() call with DOCMD_VERBOSE.
