Problem: The message for yanking doesn't indicate the register.
Solution: Show the register name in the "N lines yanked" message. (Lemonboy,
closesvim/vim#1803, closesvim/vim#1809)
e45deb7997
Looking at the implementation of u_save suggests that its failure is
a normal and expected situation (e.g. if undo isn't allowed for some
reason, it will fail). Also (most of) the other calls to u_save() in
do_put() return early.
vim-patch:8.0.0234: crash when using put in Visual mode
Problem: When several lines are visually selected and one of them is short,
using put may cause a crash. (Axel Bender)
Solution: Check for a short line. (Christian Brabandt)
941c12da3c
vim-patch:8.0.0236: gcc complains about uninitialized variable
Problem: Gcc complains that a variable may be used uninitialized. Confusion
between variable and label name. (John Marriott)
Solution: Initialize it. Rename end to end_lnum.
6a717f17ec
vim-patch:8.0.0225: put in Visual block mode terminates early
Problem: When a block is visually selected and put is used on the end of
the selection only one line is changed.
Solution: Check for the end properly. (Christian Brabandt, neovim issue
5781)
9957a10d0f
Problem: Invalid memory access in read_redo(). (gy741)
Solution: Convert the replacement character back from a negative number to
CR or NL. (hint by Dominique Pelle, closesvim/vim#2616)
f12519dec8
Problem: Diff mode is displayed wrong when adding a line at the end of a
buffer.
Solution: Adjust marks in diff mode. (James McCoy, closesvim/vim#1329)
f58a8475e1
vim-patch:8.0.0291
Problem: Visual block insertion does not insert in all lines.
Solution: Don't bail out of insert too early. Add a test. (Christian
Brabandt, closesvim/vim#1290)
23fa81d222
vim-patch:8.0.0282
Problem: When doing a Visual selection and using "I" to go to insert mode,
CTRL-O needs to be used twice to go to Normal mode.
(Coacher)
Solution: Check for the return value of edit(). (Christian Brabandt,
closes#1290)
0b5c93a7f2
- Show hint only once per session.
- provider#clipboard#Call(): prevent recursion
- provider#clear_stderr(): use has_key(), because :silent! is still
captured by :redir.
closes#7184
start_batch_changes() doesn't avoid invoking the clipboard
once-per-line, because the loop is actually in ex_echo(), which calls
redir_write() for each message. But we've already entered
start_batch_changes() by then, so that was never the problem.
redir_write at /home/vagrant/old.neovim/build/../src/nvim/message.c:2523
msg_puts_attr_len at /home/vagrant/old.neovim/build/../src/nvim/message.c:1600
msg_outtrans_len_attr at /home/vagrant/old.neovim/build/../src/nvim/message.c:1221
ex_echo at /home/vagrant/old.neovim/build/../src/nvim/eval.c:19433
do_one_cmd at /home/vagrant/old.neovim/build/../src/nvim/ex_docmd.c:2242
Trying to defer _explicit_ clipboard updates is difficult.
:redir @+ | silent echo system('cat foo') | redir END
is essentially equivalent to:
for l in readfile('foo')
let @+ .= l
endfor
We cannot make judgements about when to ignore a script's bad decisions.
start_batch_changes() only works around the case of clipboard=unnamed,
i.e. _implicit_ clipboard updates (`:g/foo/d`). Not explicit
assignment.
redir_write():
- This is a "batch" operation which was not yet covered by
start_batch_changes()
adjust_clipboard_name():
- msg() and friends during :redir will, of course, cause redir_write()
to try to capture that message, which causes recursion.
- EMSG() here is trouble: if it interrupts :redir it is a mess.
Rather than deal with the mess, show a non-error message.
closes#7182closes#7184closes#7183
ref #6048
ref #7032
if (oap->regname == 0 &&
oap->motion_type != kMTLineWise &&
oap->line_count == 0 &&
!oap->use_reg_one ){
then reg is not initialised
and our call to set_clipboard will dereference NULL
}
