- Avoid using platform-specific shell, it failed in MINGW_64 env.
- tty-test.c echos our input, which is exactly what we need for this test.
- Test fails correctly if 894f6bee54 is reverted.
wp->w_height_inner now contains the "inner" size, regardless if the
window has been drawn yet or not. It should be used instead of
wp->w_grid.Rows, for stuff that is not directly related to accessing
the allocated grid memory, such like cursor movement and terminal size
- Return the menu properties, not only its children.
- If the {path} param is given, return only the first node. The "next"
nodes in the linked-list are irrelevant.
:menu should print sub-menu contents. E.g. this should print the
"File.Save" submenu:
nvim -u NORC
:source $VIMRUNTIME/menu.vim
:menu File.Save
Regressed in dc685387a3
Blocks #8173
menu_get() also was missing some results for some cases.
- Any long symbol is intentional and should never be hardwrapped.
- Vim help tags are often hyphenated, and hardwrapping on hyphens breaks
the Vim help syntax parser.
Problem: Showing two characters for tab is limited.
Solution: Allow for a third character for "tab:" in 'listchars'. (Nathaniel
Braun, Ken Takata, closesvim/vim#3810)
83a52171ba
Previously the mouse tests set 'listchars', but not 'list'. Funnily enough, the
space, where the `$` would normally appear, would still use new highlight group.
Set 'list' for good and fix the tests accordingly.
Using 'listchars' is a nice way to highlight tabs that were included by accident
for buffers that set 'expandtab'.
But maybe one does not want this for buffers that set 'noexpandtab', so now one
can use:
autocmd FileType go let &l:listchars .= ',tab: '
Add 'multiline' flag to history for correct :messages output
Use larger buffer size for multiline messages. if this turns out to not
be enough, we could do size calculation like api_set_error
closes#8274
The parent commit tries a different approach, but that fails on Apple
Clang version:
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
which somehow compiles the check_c_source_compiles() check, but then
complains during later compilation that __fpclassify is not defined
(regardless of "#include <math.h>").
There was never any investigation done to determine whether using
jemalloc was actually a net benefit for nvim. It has been a portability
limitation and adds another factor to consider when triaging issues.
Reverts previous experiment. PVS root is working correctly, one can
observe this in the PVS-studio.err file, for example:
/usr/local/clang-7.0.0/lib/clang/7.0.0/include/stddef.h:51:1: warning: V677 ...
/usr/local/clang-7.0.0/lib/clang/7.0.0/include/stddef.h:132:1: warning: V677 ...
./src/nvim/fileio.c:1382:1: warning: V1026 ...
./src/nvim/fileio.c:1388:1: warning: V1026 ...
The "./src/nvim/…" paths are correctly rooted, yet PVS somehow still
thinks it should analyze "/usr/local/clang-7.0.0/…".
See also: https://stackoverflow.com/q/44906903
