Closes#7086
Problem: Storing a zero byte from a multi-byte character causes fold text
to show up wrong.
Solution: Avoid putting zero in ScreenLines. (Christian Brabandt,
closesvim/vim#1567)
c6cd8409c2
vim-patch:8.0.0290: cursor positioning wrong if wide character wraps
Problem: If a wide character doesn't fit at the end of the screen line, and
the line doesn't fit on the screen, then the cursor position may
be wrong. (anliting)
Solution: Don't skip over wide character. (Christian Brabandt, closes vim/1408)
vim-patch:8.0.0394
Problem: Tabs are not aligned when scrolling horizontally and a Tab doesn't
fit. (Axel Bender)
Solution: Handle a Tab as a not fitting character. (Christian Brabandt)
Also fix that ":redraw" does not scroll horizontally to show the
cursor. And fix the test that depended on the old behavior.
abc39ab642
Problem: Linebreak tests are old style.
Solution: Turn the tests into new style. Share utility functions. (Ozaki
Kiichi, closesvim/vim#1444)
544d3bc9f0
Problem: Display problem with 'foldcolumn' and a wide character.
(esiegerman)
Solution: Don't use "extra" but an allocated buffer. (Christian Brabandt,
closesvim/vim#1310)
6270660611
32396b5879 add length checks to
TERMINAL_FAMILY/STARTS_WITH to ensure memcmp() wouldn't read past the
end of the string. However, "term" was copy/pasted from TERMINAL_FAMILY
so STARTS_WITH() was unnecessarily reading the, potentially NULL, term
variable.
Closes#4370
Explication:
In the backtrace in #4370, we see that `buf_write()` was called with
non-NULL `fname` and `sfname` arguments, but they've since _become_
NULL.
#7 0x00000000004de09d in buf_write (buf=0x1dee040, fname=0x0, fname@entry=0x1e985b0 "/home/sean/src/github.com/snczl/virta/pkg/meld/segment.go",
sfname=0x0, sfname@entry=0x1ddfa60 "segment.go", start=1, end=72, eap=eap@entry=0x7ffc6b032e60, append=0,
forceit=0, reset_changed=1, filtering=0)
at /home/travis/build/neovim/bot-ci/build/neovim/src/nvim/fileio.c:2576
This is most likely due to the code that restores those values from
`buf`, which happens just before the fatal call to `os_fileinfo`
```c
/*
* The autocommands may have changed the name of the buffer, which may
* be kept in fname, ffname and sfname.
*/
if (buf_ffname)
ffname = buf->b_ffname;
if (buf_sfname)
sfname = buf->b_sfname;
if (buf_fname_f)
fname = buf->b_ffname;
if (buf_fname_s)
fname = buf->b_sfname;
```
It's worth noting that at this point `ffname` is still non-NULL, so
it _could_ be used. However, our current code is purely more strict
than Vim in this area, which has caused us problems before (e.g.,
`getdigits()`). The commentary for `struct file_buffer` clearly
indicate that all of `b_ffname`, `b_sfname`, and `b_fname` may be
NULL:
```c
/*
* b_ffname has the full path of the file (NULL for no name).
* b_sfname is the name as the user typed it (or NULL).
* b_fname is the same as b_sfname, unless ":cd" has been done,
* then it is the same as b_ffname (NULL for no name).
*/
char_u *b_ffname; /* full path file name */
char_u *b_sfname; /* short file name */
char_u *b_fname; /* current file name */
```
Vim directly calls `stat(2)` which, although it is annotated to tell
the compiler that the path argument is non-NULL, does handle a NULL
pointer by returning a `-1` value and setting `errno` to `EFAULT`.
This satisfies Vim's check, since it treats any `-1` return from
`stat(2)` to mean the file doesn't exist (at least in this code
path).
Note that Vim's mch_stat() implementations on win32 and solaris
clearly cannot accept NULL `name`. But the codepaths that call
mch_stat will NULL `name` tend to be unix-only (eg: u_read_undo)!
Problem: ":earlier" and ":later" do not work after startup or reading the
undo file.
Solution: Use absolute time stamps instead of relative to the Vim start
time. (Christian Brabandt, Pavel Juhas, closesvim/vim#1300, closes
vim/vim#1254)
cbd4de44e8
Problem: searchpair() does not work when 'magic' is off. (Chris Paul)
Solution: Add \m in the pattern. (Christian Brabandt, closesvim/vim#1341)
6e450a5754
Problem: When 'maxfuncdepth' is set above 200 the nesting is limited to
200. (Brett Stahlman)
Solution: Allow for Ex command recursion depending on 'maxfuncdepth'.
777b30f827
Unlike the normal wildmenu, the CTRL-D wild-list is not restored by
statusline redraw. (Semantics: ^D is controlled by 'wildoptions' option,
so it's in the "wild..." family.)
TODO: externalize the c_CTRL-D wild-list.
This might be too coarse, but it passes all tests ...
A more nuanced approach might be: only skip the windows whose
statuslines are overwritten by the wildmenu.
Closes#2255Closes#7108
vim-patch:8.0.0710 N/A because of the changes in this commit.
Problem: Null pointer access reported by UBsan.
Solution: Check curwin->w_buffer is not NULL. (Yegappan Lakshmanan)
c4bfedabe0
src/nvim/ex_cmds.c have been merged by someone. while version.c remain unmerged.
This reverts commit eb40b7ec40.
The change caused this error on QuickBuild:
INFO - # test/functional/core/job_spec.lua @ 668: pty process teardown does not prevent/delay exit. #4798#4900
INFO - not ok 321 - pty process teardown does not prevent/delay exit. #4798#4900
INFO - # test/functional/core/job_spec.lua @ 668
INFO - # Failure message: ./test/functional/ui/screen.lua:302: Row 1 did not match.
INFO - # Expected:
INFO - # |* |
INFO - # |[Process exited 0] |
INFO - # | |
INFO - # | |
INFO - # | |
INFO - # |-- TERMINAL -- |
INFO - # Actual:
INFO - # |*E575: Error while reading ShaD|
INFO - # |a file: mark entry at position|
INFO - # | 92 has invalid line number |
INFO - # |Press ENTER or type command to|
INFO - # | continue |
INFO - # |-- TERMINAL -- |
INFO - #
INFO - # To print the expect() call that would assert the current screen state, use
INFO - # screen:snaphot_util(). In case of non-deterministic failures, use
INFO - # screen:redraw_debug() to show all intermediate screen states.
INFO - # stack traceback:
INFO - # ./test/functional/ui/screen.lua:302: in function 'wait'
INFO - # ./test/functional/ui/screen.lua:216: in function 'expect'
INFO - # test/functional/core/job_spec.lua:677: in function <test/functional/core/job_spec.lua:668>
