Problem: Using :pedit from a help file sets the preview window to help
filetype. (Wang Shidong)
Solution: Do not set "keep_help_flag". (closesvim/vim#3536)
026587b35c
Test52 does nothing on UNIX. And vim on Windows performs mbyte-conversion
between Unicode and code page using Windows API(See :h mbyte-conversion).
Test52 seems to be testing its functionality. In neovim, the conversion
function by Windows API has been removed. Therefore, there is no point
in doing this test.
../src/nvim/os/fs.c: In function 'os_can_exe':
../src/nvim/os/fs.c:247:27: warning: passing argument 1 of 'is_executable_ext' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
247 | if (is_executable_ext(name, abspath)) {
| ^~~~
In file included from ../src/nvim/os/fs.c:36:
src/nvim/auto/os/fs.c.generated.h:7:38: note: expected 'char *' but argument is of type 'const char *'
7 | static _Bool is_executable_ext(char *name, char **abspath) FUNC_ATTR_NONNULL_ARG(1);
| ~~~~~~^~~~
../src/nvim/os/fs.c: In function 'os_resolve_shortcut':
../src/nvim/os/fs.c:1183:56: warning: conversion from 'size_t' {aka 'const long long unsigned int'} to 'int' may change value [-Wconversion]
1183 | const int conversion_result = utf8_to_utf16(fname, len, &p);
| ^~~
../src/nvim/os/fs.c:1211:19: warning: declaration of 'conversion_result' shadows a previous local [-Wshadow]
1211 | const int conversion_result = utf16_to_utf8(wsz, -1, &rfname);
| ^~~~~~~~~~~~~~~~~
../src/nvim/os/fs.c:1183:15: note: shadowed declaration is here
1183 | const int conversion_result = utf8_to_utf16(fname, len, &p);
| ^~~~~~~~~~~~~~~~~
- take a size parameter
- always NUL-terminate the result
- return libuv error code
- handle error in caller only (avoid redundant messages)
53995a38254c945f4936
The screen resize logic needs to be refactored to be simpler and more
deterministic. Until then, we need to handle attempts to draw outside of the
screen size gracefully, just like the old vim code did.
fixes#9989
If parse_shape_opt() is done before user config, the TUI may cause
unwanted changes to the terminal cursor which cannot later be undone
(see #4396).
fix#10750
Problem: Test listed as flaky should no longer be flaky.
Solution: Remove Test_popup_and_window_resize from the list of flaky tests.
(Daniel Hahler, closevim/vim#4807)
9570aacdb8
Problem: Test_popup_and_window_resize() does not always pass.
Solution: Do not use $VIMPROG, pass the Vim executable in the vimcmd file.
(Ozaki Kiichi, closesvim/vim#2186)
631820536e
vim-patch:8.0.1526: no test using a screen dump yet
Problem: No test using a screen dump yet.
Solution: Add a test for C syntax highlighting. Add helper functions.
da65058a9c
NOTE: uses modified `GetVimProg()` (which is used with skipped tests only
(mostly because of `!has('terminal')`)).
Vim uses a 'vimcmd' file, while Nvim uses `$NVIM_TEST_ARGX` environment
variables.
Ref: https://github.com/vim/vim/pull/4806
Before this commit, when `inccomand` was set to `nosplit`, multi-line
substitutions collapsed the command-line.
This happened because when ex_getln.c:cursorcmd() computed a msg_row, it
was given a cmdline_row one line too high. This happened because
message.c:msg_puts_display() was supposed to decrement cmdline_row but
didn't, because of the `msg_no_more && lines_left == 0` check placed
just before the decrementation part in msg_puts_display's while loop.
Every time msg_puts_display writes a line, it decreases `lines_left` (a
variable used to know how many lines are left for prompts). Since
redrawcommandline() did not reset `lines_left` between calls to
msg_puts_display, every time a character was pressed, `lines_left` was
decremented. This meant that once the user pressed COLUMNS+ROWS numbers
of characters, `lines_left` would reach 0 and prevent msg_row from being
decremented.
It makes sense to fix setting `lines_left` to `cmdline_row` in
`compute_cmdrow` ; after all, computing where the command line row
should be placed is equivalent to computing how many `lines_left` of
output there are left.
Closes#8254.
- Re-enable Test_BufLeave_Wipe. 66f5e5c7d7
This is my (probably-wrong) application of Zyx's suggestion in #9163:
> free_buffer_stuff() already removes changedtick. It is better to
> make `free_options` a flag variable and avoid calling
> buf_init_changedtick() based on some flag there: current workflow
> looks weird as it first removes `b:changedtick`, then re-adds it
> by calling buf_init_changedtick(), then remove again.
> Also based on my understanding it looks logical to not remove
> `b:changedtick`, but to *replace* it with something allocated if
> needed based on examining reference count before calling
> `unref_var_dict`. Because now you have key disappearing from
> dictionary for no good reason.
Patch-By: Nikolai Aleksandrovich Pavlov <kp-pav@yandex.ru>
Problem: Crash when wiping out a buffer after using getbufinfo().
(Yegappan Lakshmanan)
Solution: Remove b:changedtick from the buffer variables.
(Note: The test changes in vim-patch:8.0.1193 were already included.)
