f04507d132
Author: Bram Moolenaar <Bram@vim.org>
Date: Sat Aug 20 15:05:39 2016 +0200
patch 7.4.2229
Problem: Startup test fails on Solaris.
Solution: Recognize a character device. (Danek Duvall)
f71d7b9ee5
Author: Bram Moolenaar <Bram@vim.org>
Date: Tue Aug 9 22:14:05 2016 +0200
patch 7.4.2189
Problem: Cannot detect encoding in a fifo.
Solution: Extend the stdin way of detecting encoding to fifo. Add a test
for detecting encoding on stdin and fifo. (Ken Takata)
Problem: The example that explains nested backreferences does not work
properly with the new regexp engine. (Harm te Hennepe)
Solution: Also save the end position when adding a state. (closesvim/vim#990)
d563883a1f
The libvte test was too agressive, and is reduced to only triggering
when it is libvte 0.36 AND a gnome or xterm terminal type is used.
Contrastingly, tmux was not on the list at all and now is.
During a preview, we can stop looking for matches after we got enough
lines for the preview buffer.
Because of this perf improvement, the 'redrawtime' test needs to be
slowed down in a different way: _long_ lines instead of just many lines.
The gchar_cursor() == NUL check is already done in ins_ctrl_o.
ins_esc changes gchar_cursor() so this if block is probably never
entered.
Issue:
Pressing CTRL-O in insert mode at the end of the line and typing
:startinsert moves the cursor 1 column back, when I expect the cursor
to remain at the end of the line
This is a regression from Vim behavior. Since at least Vim version 7.0,
Vim returns you to insert mode at the end of the line.
091e7d033c is the first bad neovim commit
Steps to reproduce using `nvim -u NORC`:
`aaaa<C-o>:startinsert<CR>`
Fixes#6962
Update a flawed match pattern for the vimCommand syntax group. To see
the effect of this fix, open a vimscript buffer,
nvim -u NONE foo.vim
configure a couple highlight groups,
:hi! vimIsCommand ctermfg=Green
:hi! vimCommand ctermfg=Red
:syntax enable
and add the following lines to the buffer:
let foo=xFoo
let bar=zBar
You'll notice the "z" in zBar is Red, while xFoo and the rest of Bar are green. This will
be the case as long as the word following `=` starts with the letter "z". This has already
been fixed upstream by adding a "\>" word boundary to the match pattern:
https://github.com/vim/vim/issues/124e271909625 (diff-86da060e2153c8ce5dc317a7b4b5a29dR27)
This particular match pattern was also mentioned in issue #5491, but in reference to a bug
that was related to the generated part of syntax/vim.vim, whereas this bug lives in the
non-generated part of the file.
The terminfo doco explicitly states that it covers the case where the
terminal is in application cursor/keypad (i.e. "keypad transmit") mode,
and not where it is in normal cursor/keypad (i.e. "keypad local") mode.
Full screen applications like nvim must switch to and from keypad
transmit mode when expecting the control sequences given by terminfo.
This is the result of malloc error handling elimination: push_current_state()
used to (not) return OK depending on whether growing garray failed or not and
this return was checked, if errorred out push_next_match() will simply return
its argument unchanged.
Now when allocations are supposed to either always succeed or crash Neovim this
check was returned, push_current_state() was stripped of its return value and
moved out of if() condition, resulting in V763.
