Why?
- Because we can.
- Because the TUI is just another GUI™
- Because it looks kinda nice, and provides useful context like 1 out of 100
times
Complies with "don't pay for what you don't use".
Some crashes for resizing were unfolded, add tests for those.
Makes the 'scrollback' option more consistent (same default for all buffers) and future-proof.
- Default to -1 for all buffers, but treat it as an implementation detail.
- Document range of 1 - 100_000.
- New terminal buffer by default sets scrollback=10_000 if the global default is -1.
- Existing terminal buffer: On entering terminal-mode or on refresh, if the user explicitly did `:set[local] scbk=-1`, the local value goes to 100_000 (max). (This is undocumented on purpose. Users should work with explicit values in the range of 1-100_000.)
Problem: No debugger making use of the terminal window.
Solution: Add the term debugger plugin. So far only displays the current
line when stopped.
fe386641b0
- 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.
- 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
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: '
Instead of eager-loading during plugin/* sourcing, define runtime
modules such as `vim.inspect` as lazy builtins. Otherwise non-builtin
Lua modules such as `vim.inspect` would not be available during startup
(init.vim, `-c`, `--cmd`, …).
ref #6580
ref #8677
Problem: Custom operators can't act upon a forced motion. (Christian
Wellenbrock)
Solution: Add the forced motion to the mode() result. (Christian Brabandt,
closesvim/vim#3490)
5976f8ff00closes#8667closes#9476
Christian Wellenbrock:
> For (most) built in text objects it's possible to force operation on
> them to be linewise, for example by using `dVab` (`:h o_V`,
> `motion_force`). When using custom text objects (defined as mappings
> by plugins for example), this doesn't currently work.
>
> Example:
>
> onoremap x viw
>
> Open a file with a few lines each containing some words. With the
> cursor on any word, try:
>
> 1. `dw` (builtin) deletes some characters
> 2. `dVw` (builtin) deletes linewise
> 3. `dx` (from mapping) deletes some characters
> 4. `dVx` (from mapping) deletes some characters, but should delete
> linewise
ref: https://github.com/wellle/targets.vim/issues/214
ref: https://gitter.im/neovim/neovim?at=5b379ff7f1664406610e7483
Decide whether to highlight the visual-selected character under the
cursor, depending on 'guicursor' style:
- Highlight if cursor is blinking or non-block (vertical, horiz).
- Do NOT highlight if cursor is non-blinking block.
Traditionally Vim's visual selection does "reverse mode", which perhaps
conflicts with the non-blinking block cursor. But 'guicursor' defaults
to a vertical bar for selection=exclusive, and this confuses users who
expect to see the text highlighted.
closes#8983
Problem: It is not so easy to write a script that works with both Python 2 and Python 3, even when the Python code works with both.
Solution: Add 'pyxversion', :pyx, etc. (Marc Weber, Ken Takata)
f42dd3c390
The neovim module is available for backwards compatibility. We should
not yet force the use of the pynvim module, since there's no other major
reason to bump the minimum supported Python client module.
Closes#9426
This avoids generating the tags files all the time, and makes `make
install` with `CMAKE_INSTALL_MESSAGE=LAZY` much more silent in general.
Using `copy_if_different` instead of `remove` + `copy_directory` might
be good on top, but is a) not really necessary anymore and b) would not
sync removed files.
For this `file(COPY` could be used, but would require to re-run cmake on
changed input files then.
The purpose of the {Nvim} hint was not well-defined, and its usage
inconsistent. It's also unnecessary.
Nvim-Vim differences are centralized at:
:help vim-differences
Removed things are centralized at:
:help deprecated
Developer guidelines for documentation are listed at:
:help dev-doc
ref #9280
Introduce the `vim.compat` module, to help environments with system Lua
5.2+ run the build/tests. Include the module implicitly in all tests.
ref #8677
legacy `vim` module:
beep
buffer
command
dict
eval
firstline
lastline
line
list
open
type
window
Problem: Cannot act on edits in the command line.
Solution: Add the CmdlineChanged autocommand event. (xtal8, closesvim/vim#2603,
closesvim/vim#2524)
153b704e20
In Vim (and some vestigial parts of Nvim) E319 was a placeholder for
ex_ni commands, i.e. commands that are only available in certain builds
of Vim. That is obviously counter to Nvim's goals: all Nvim commands
are available on all platforms and build types (the remaining ex_ni
commands are actually just missing providers).
We need an error id for "missing provider", so it makes sense to use
E319 for that purpose.
ref #9344
ref #3577
