There is no reason for this file to be in project root, which is crowded
as is. This also fits nicely part of the ongoing work towards gathering
as much of the documentation as possible into one place.
runtime(doc): clarify behaviour of ]m and ]M motions
In particular remove the sentence, that a missing '{'
(for ]m) or '}' (for ]M) after the cursor is an error, since
currently this is not treated as an error.
fixes: vim/vim#1377765672ae118
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(r): Update R runtime files and docs (vim/vim#13757)
* Update R runtime files
- Fix indentation issue with ggplot().
- Setlocal autoindent in indent/r.vim.
- New syntax option: rmd_include_latex.
- Clear syn iskeyword to recognize _ as keyword.
- Document some options.
- remove the test has("patch-7.4.1142")
- Update changed date of doc files
9042bd8b09
Co-authored-by: Jakson Alves de Aquino <jalvesaq@gmail.com>
The purpose of this commit is to make diff clean and easy to read; to
see the diff resulted from actual changes in gen_lsp.lua, not from the
updated LSP protocol JSON data.
Ran: `nvim -l scripts/gen_lsp.lua gen --methods`
Based on 3.18.0 (2023-12-23)
Problem: Unable to predict which byte-offset to place virtual text to
make it repeat visually in the wrapped part of a line.
Solution: Add a flag to nvim_buf_set_extmark() that causes virtual
text to repeat in wrapped lines.
Problem: Maximum callback depth is not configurable.
Solution: Revert patch 9.0.2103. Set 'maxfuncdepth' in test.
fixes: vim/vim#13732closes: vim/vim#13736fe583b1e59
Problem:
Bundled color schemes use `:hi clear` and only define Vim's highlight
groups. This results into Nvim-specific highlight groups using
definitions from Nvim's default color scheme, which are not always
linked to a Vim's highlight group.
Solution:
Restore links to Vim's highlight groups which were present before Nvim's
default color scheme update.
Problem: Not all default highlight groups show their actual colors.
Solution: Refactor `vimhelp.lua` and apply it to all relevant lists (UI
groups, syntax groups, treesitter groups, LSP groups, diagnostic groups).
Diagnostic signs should now be configured with vim.diagnostic.config(),
but "legacy" sign definitions should go through the standard deprecation
process to minimize the impact from breaking changes.
Problem:
- The :Evaluate result window is not cleaned up when the cursor moves.
- This window is not focusable.
Solution:
Replace the old implementation from autozimu/LanguageClient-neovim with
vim.lsp.util.open_floating_preview and implement custom focusing logic.
Also remove g:termdebug_useFloatingHover option now that it's working
correctly.
runtime(fortan): update fortran syntax rules and doc notes
Update to the Fortran 2023 standard. Reorganize some code to reflect the
dropping of dialect support in the previous commit. Minor improvements.
closes: vim/vim#1371271cbe8e17a
Co-authored-by: Ajit-Thakkar <142174202+Ajit-Thakkar@users.noreply.github.com>
Currently, setting &bg at all re-initializes highlights and reloads
the active colorscheme, even if the actual value of &bg has not changed.
With https://github.com/neovim/neovim/pull/26595 this causes a
regression since &bg is set unconditionally based on the value detected
from the terminal.
Instead, only reload the colorscheme if the actual value of &bg has
changed.
runtime(doc): remove deprecation warning for gdefault
Deprecated can be misunderstood as being slated for removal; slightly
change wording to be clearer.
82f19734bf
Co-authored-by: dundargoc <gocdundar@gmail.com>
Problem: Updating default color scheme produced some feedback.
Solution: Address the feedback.
Outline of the changes:
- Colors `Grey1` and `Grey2` are made a little bit more extreme (dark -
darker, light - lighter) to increase overall contrast.
- `gui` colors are treated as base with `cterm` colors falling back to
using 0-15 colors which come from terminal emulator.
- Update highlight group definition to not include attribute definition
if it is intended to staty uncolored.
- Tweak some specific highlight groups.
- Add a list of Neovim specific highlight groups which are now defined
differently in a breaking way.
- Minor tweaks in several other places related to default color scheme.
Problem: We have `P_(BOOL|NUM|STRING)` macros to represent an option's type, which is redundant because `OptValType` can already do that. The current implementation of option type flags is also too limited to allow adding multitype options in the future.
Solution: Remove `P_(BOOL|NUM|STRING)` and replace it with a new `type_flags` attribute in `vimoption_T`. Also do some groundwork for adding multitype options in the future.
Side-effects: Attempting to set an invalid keycode option (e.g. `set t_foo=123`) no longer gives an error.
Problem:
Unlike termopen(), nvim_open_term() PTYs do not carriage-return the
cursor on newline ("\n") input.
nvim --clean
:let chan_id = nvim_open_term(1, {})
:call chansend(chan_id, ["here", "are", "some", "lines"])
Actual behavior:
here
are
some
lines
Expected behaviour:
here
are
some
lines
Solution:
Add `force_crlf` option, and enable it by default.
Problem: Wiki contents are not discoverable and hard to maintain.
Solution: Move FAQ to runtime docs.
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
* fix garbled item for new treesitter injection format
* add missing item for new `vim.lpeg` and `vim.re`
* use taglinks where possible
* remove redundant "Added" and "Removed" from items
runtime(doc): link cmdline completion to to |wildcards| and fix typos (vim/vim#13636)
The docs for cmdline completion doesn't mention that [abc] is considered
a wildcard, and |wildcards| contains more detailed information, so just
link to it.
Also fix some typos in other help files.
61e984e212
Enable 'termguicolors' automatically when Nvim can detect that truecolor
is supported by the host terminal.
If $COLORTERM is set to "truecolor" or "24bit", or the terminal's
terminfo entry contains capabilities for Tc, RGB, or setrgbf and
setrgbb, then we assume that the terminal supports truecolor. Otherwise,
the terminal is queried (using both XTGETTCAP and SGR + DECRQSS). If the
terminal's response to these queries (if any) indicates that it supports
truecolor, then 'termguicolors' is enabled.
Problem:
Empty string is a valid JSON key, but json_decode() treats an object
with empty key as ":help msgpack-special-dict". #20757
:echo json_decode('{"": "1"}')
{'_TYPE': [], '_VAL': [['', '1']]}
Note: vim returns `{'': '1'}`.
Solution:
Allow empty string as an object key.
Note that we still (currently) disallow empty keys in object_to_vim() (since 7c01d5ff92):
f64e4b43e1/src/nvim/api/private/converter.c (L333-L334)Fix#20757
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
runtime(doc): remove non-existent parameter in shift-command (vim/vim#13626)
The variant with the {count} parameter is explained in the next item.
2103a56eab
N/A patches:
vim-patch:9.0.2150: Using int for errbuflen in option funcs
vim-patch:3f7855a6123c
Co-authored-by: Roy Orbitson <Roy-Orbison@users.noreply.github.com>
PROBLEM: `vim.treesitter.get_node()` does not recognize the `lang` in
the option table. This option was used in somewhere else, for instance,
`vim.treesitter.dev` (for `inspect_tree`) but was never implemented.
SOLUTION: Make `get_node()` correctly use `opts.lang` when getting a
treesitter parser.
Problem: Default color scheme is suboptimal.
Solution: Start using new color scheme. Introduce new `vim` color scheme
for opt-in backward compatibility.
------
Main design ideas
- Be "Neovim branded".
- Be minimal for 256 colors with a bit more shades for true colors.
- Be accessible through high enough contrast ratios.
- Be suitable for dark and light backgrounds via exchange of dark and
light palettes.
------
Palettes
- Have dark and light variants. Implemented through exporeted
`NvimDark*` and `NvimLight*` hex colors.
- Palettes have 4 shades of grey for UI elements and 6 colors (red,
yellow, green, cyan, blue, magenta).
- Actual values are computed procedurally in Oklch color space based on
a handful of hyperparameters.
- Each color has a 256 colors variant with perceptually closest color.
------
Highlight groups
Use:
- Grey shades for general UI according to their design.
- Bold text for keywords (`Statement` highlight group). This is an
important choice to increase accessibility for people with color
deficiencies, as it doesn't rely on actual color.
- Green for strings, `DiffAdd` (as background), `DiagnosticOk`, and some
minor text UI elements.
- Cyan as main syntax color, i.e. for function usage (`Function`
highlight group), `DiffText`, `DiagnosticInfo`, and some minor text UI
elements.
- Red to generally mean high user attention, i.e. errors; in particular
for `ErrorMsg`, `DiffDelete`, `DiagnosticError`.
- Yellow very sparingly only with true colors to mean mild user
attention, i.e. warnings. That is, `DiagnosticWarn` and `WarningMsg`.
- Blue very sparingly only with true colors as `DiagnosticHint` and some
additional important syntax group (like `Identifier`).
- Magenta very carefully (if at all).
------
Notes
- To make tests work without relatively larege updates, each one is
prepended with an equivalent of the call `:colorscheme vim`.
Plus some tests which spawn new Neovim instances also now use 'vim'
color scheme.
In some cases tests are updated to fit new default color scheme.
FUNC_ATTR_* should only be used in .c files with generated headers.
Defining FUNC_ATTR_* as empty in headers causes misuses of them to be
silently ignored. Instead don't define them by default, and only define
them as empty after a .c file has included its generated header.
Problem: No test for mode() when executing Ex commands
Solution: Add some test cases and simplify several other test cases.
Also add a few more test cases for ModeChanged.
closes: vim/vim#13588fcaeb3d42b
decor->text.str pointer must go. This removes it for conceal char,
in preparation for a larger PR which will also handle the sign case.
By actually allowing composing chars for a conceal chars, this
becomes a feature and not just a refactor, as a bonus.
Problem: Unable to identify legacy signs when fetching extmarks with
`nvim_buf_get_extmarks()`.
Solution: Add "sign_name" to the extmark detail array.
Add some misc. changes as follow-up to #25724
runtime(doc): Fix whitespace and formatting of some help files (vim/vim#13549)
596a9f29c8
N/A patch:
vim-patch:aabca259fa48
Co-authored-by: h_east <h.east.727@gmail.com>
Problem: The legacy signlist data structures and associated functions are
redundant since the introduction of extmark signs.
Solution: Store signs defined through the legacy commands in a hashmap, placed
signs in the extmark tree. Replace signlist associated functions.
Usage of the legacy sign commands should yield no change in behavior with the
exception of:
- "orphaned signs" are now always removed when the line it is placed on is
deleted. This used to depend on the value of 'signcolumn'.
- It is no longer possible to place multiple signs with the same identifier
in a single group on multiple lines. This will now move the sign instead.
Moreover, both signs placed through the legacy sign commands and through
|nvim_buf_set_extmark()|:
- Will show up in both |sign-place| and |nvim_buf_get_extmarks()|.
- Are displayed by increasing sign identifier, left to right.
Extmark signs used to be ordered decreasingly as opposed to legacy signs.
Problem: buffer text with composing chars are converted from UTF-8
to an array of up to seven UTF-32 values and then converted back
to UTF-8 strings.
Solution: Convert buffer text directly to UTF-8 based schar_T values.
The limit of the text size is now in schar_T bytes, which is currently
31+1 but easily could be raised as it no longer multiplies the size
of the entire screen grid when not used, the full size is only required
for temporary scratch buffers.
Also does some general cleanup to win_line text handling, which was
unnecessarily complicated due to multibyte rendering being an "opt-in"
feature long ago. Nowadays, a char is just a char, regardless if it consists
of one ASCII byte or multiple bytes.
Problem: [security]: overflow with count for :s command
Solution: Abort the :s command if the count is too large
If the count after the :s command is larger than what fits into a
(signed) long variable, abort with e_value_too_large.
Adds a test with INT_MAX as count and verify it correctly fails.
It seems the return value on Windows using mingw compiler wraps around,
so the initial test using :s/./b/9999999999999999999999999990 doesn't
fail there, since the count is wrapping around several times and finally
is no longer larger than 2147483647. So let's just use 2147483647 in the
test, which hopefully will always cause a failure
ac63787734
Co-authored-by: Christian Brabandt <cb@256bit.org>
Use the XTGETTCAP sequence to determine if the host terminal supports
the OSC 52 sequence and, if it does, enable the OSC 52 clipboard
provider by default.
This is only done automatically when all of the following are true:
1. Nvim is running in the TUI
2. 'clipboard' is not set to unnamed or unnamedplus
3. g:clipboard is unset
4. Nvim is running in an SSH connection ($SSH_TTY is set)
5. Nvim is not running inside tmux ($TMUX is unset)
The 'termsync' option enables a mode (provided the underlying terminal
supports it) where all screen updates during a redraw cycle are buffered
and drawn together when the redraw is complete. This eliminates tearing
or flickering in cases where Nvim redraws slower than the terminal
redraws the screen.
Problem:
Platform-specific UI providers should live in `vim.ui.*`. #24164
Solution:
- Move `vim.clipboard.osc52` module to `vim.ui.clipboard.osc52`.
- TODO: move all of `clipboard.vim` to `vim.ui.clipboard`.
ref #25872
Problem:
'nofsync' may lose data if the system has a hard shutdown. #9888
Solution:
Change default to 'fsync'. This may be revisited in the future when
'nofsync' can be made safer.
Problem: recursive callback may cause issues on some archs
Solution: Decrease the limit drastically to 20
Recursive callback limit causes problems on some architectures
Since commit 47510f3d6598a1218958c03ed11337a43b73f48d we have a test
that causes a recursive popup callback function to be executed. However
it seems the current limit of 'maxfuncdepth' option value is still too
recursive for some 32bit architectures (e.g. 32bit ARM).
So instead of allowing a default limit of 100 (default value for
'maxfuncdepth'), let's reduce this limit to 20. I don't think there is a
use case where one would need such a high recursive callback limit and a
limit of 20 seems reasonable (although it is currently hard-coded).
closes: vim/vim#13495closes: vim/vim#135022076463e38
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(termdebug): improve the breakpoint sign label (vim/vim#13525)
// related vim/vim#12589
// that should be the last chat (I) with Bram, r.i.p
2dd613f57b
Co-authored-by: Shane-XB-Qian <shane.qian@foxmail.com>
refactor!: `vim.lsp.inlay_hint()` -> `vim.lsp.inlay_hint.enable()`
Problem:
The LSP specification allows inlay hints to include tooltips, clickable
label parts, and code actions; but Neovim provides no API to query for
these.
Solution:
Add minimal viable extension point from which plugins can query for
inlay hints in a range, in order to build functionality on top of.
Possible Next Steps
---
- Add `virt_text_idx` field to `vim.fn.getmousepos()` return value, for
usage in mappings of `<LeftMouse>`, `<C-LeftMouse>`, etc
Problem: Not easy to filter the output of maplist().
Solution: Add mode_bits to the dictionary. (Ernie Rael, closesvim/vim#10356)
d8f5f76621
Co-authored-by: Ernie Rael <errael@raelity.com>
