Problem: Cmdline history not updated when mapping both <Up> and <CR>.
Solution: Consider the command typed when in Cmdline mode and there is
no pending input (zeertzjq).
Although the existing behavior technically does match documentation, the
"completely come from mappings" part is a bit ambiguous, because one may
argue that the command doesn't completely come from mappings as long as
the user has typed a key in Cmdline mode. I'm not entirely sure if this
change will cause problems, but it seems unlikely.
fixes: vim/vim#2771
related: neovim/neovim#36256closes: vim/vim#1860797b6e8b424
This fixes a bug introduced in 2a33b499a3d7f46dc307234847a6562cef6cf1d8:
When makeTargetinDefine ends with makeIdent, makeSpecTarget or
makeComment, the following line is also matched as makeTargetinDefine.
So, add keepend to prevent that just as makeTarget does.
related: vim/vim#18403closes: vim/vim#185707193cab6c8
Co-authored-by: Yiyang Wu <xgreenlandforwyy@gmail.com>
Problem:
Spell file downloads relied on Vimscript and netrw (:Nread). If netrw is
disabled, downloads fail.
Solution:
Port the logic to Lua as `nvim.spellfile` and wire it via a Lua plugin that
handles `SpellFileMissing`. Use `vim.net.request()` with a timeout for HTTP,
prompt via `vim.fn.input` and report via `vim.notify`.
Closes#7189
Problem:
Some LSP method handlers were making requests without specifying a
bufnr, defaulting to 0 (current). This works in most cases but
fails when client attaches to background buffers, causing
assertions in handlers to fail.
Solution:
Ensure bufnr is passed to Client.request for buffer-local methods.
**Problem:**
`vim.filetype.match({ filename = 'a.sh' })` returns `nil` because
an invalid buffer ID is passed to `vim.api.nvim_buf_get_lines()`.
For filetypes like `csh`, `txt`, or any other extensions that call
`_getlines()` or `_getline()` to detect their filetypes, the same
issue occurs.
When only the `filename` argument is passed, an error is raised
inside a `pcall()` that wraps the filetype detection function,
causing it to return no value without showing any error message.
**Solution:**
Validate the `bufnr` value in `_getlines()` and `_getline()`.
Problem: `PackChanged[Pre]` events with `kind=update` are triggered both
during plugin's initial installation and after already installed
plugin was updated.
It was a deliberate decision to allow writing only a single update
hook to act as a dedicated "build" entry point (like execute `make` or
`cargo build —release`). This mimics how other plugin managers have a
single "build" command.
This was a result of 'mini.deps' experience with the different
approach: "update" hooks are not run during install. This proved to be
confusing as it requires to write two hooks. But also the reason might
be that 'mini.deps' names it "checkout" hook instead of "update".
However, the `vim.pack` event approach makes it lower cost to handle
separate "update" and "install" events. Something like
`if ev.data.kind == 'install' or ev.data.kind == 'update' then`
instead of two autocommands.
Plus this makes clearer separation of events.
Solution: do not trigger `PackChanged[Pre] kind=update` event during
install.
Problem: Inside `PackChanged[Pre]` callbacks it might be useful to tell
if the affected plugin is active or not. It is already possible via
extra `vim.pack.get({ 'plug-name' })[1].active`, but it is not quite
user-friendly for something that might be needed frequently in real
world use cases.
Solution: Supply extra `active` event data field.
This warning doesn't really make sense, since the `enable()` call is
meant to be run before the `lsp.config` calls. It will be logged many
times (once for each enabled LSP) at startup.
This is especially annoying because calling `enable()` after
configuration causes the first opened buffer not to have its filetype
set in some situations. This is a separate bug which really needs to be
fixed, and makes this superfluous logging more likely.
The current implementation has a race condition where items are appended
to the completion list twice when a second completion runs while the
first is still going. This hotfix just deduplicates the entire list.
Co-authored-by: Tomasz N <przepompownia@users.noreply.github.com>
docs(lsp): specify exactly how `vim.lsp.config` merges configs…
Problem:
It already says that the behaviour is defined by `vim.tbl_deep_extend`,
but that can mean very different things depending on the `behavior`
parameter.
Solution:
Specify that it uses "force".
Problem: if pumblend >= 50, non-whitespace menu character gets italic,
bold, underline (or similar) attribute from the cell underneath, which
is not really useful and can't be "blended".
Solution: drop highlight combination for that special case (@zeertzjq
on #36133).
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem:
If a client doesn't have a config then an error may be thrown.
Probably caused by: 2f78ff816b
Lua callback: …/lsp.lua:442: attempt to index local 'config' (a nil value)
stack traceback:
…/lsp.lua:442: in function 'can_start'
…/lsp.lua:479: in function 'lsp_enable_callback'
…/lsp.lua:566: in function <…/lsp.lua:565>
Solution:
Not all clients necessarily have configs.
- Handle `config=nil` in `can_start`.
- If user "enables" an invalid name that happens to match a *client*
name, don't auto-detach the client.
This patch preserves indentation in comments. It work by removing the
explicit 3-space indentation and replaces with with an expression which
uses the current value with a minimum of three spaces.
Discussed in the mailing list:
https://groups.google.com/g/vim_dev/c/rn8ZLDrCbYU
Thanks to Friedrich Romstedt for reporting and Christian Brabandt for
investigating the issue.
closes: vim/vim#1856664c8105867
Co-authored-by: Marshall Ward <marshall.ward@gmail.com>
The value of this variable is evaluated when the 'filetype' option is
changed and should be a command string that will undo any configuration
changes that the plugin has made.
See :help undo_indent for details
related: vim/vim#185665ffb23c967
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Minor style and whitespace changes to the reST syntax file, to sync with
the development branch.
related: vim/vim#1856646d86979a9
Co-authored-by: Marshall Ward <marshall.ward@gmail.com>
Escape character support was disabled for inline literals, which are
handled separately from standard inline highlights, in that escape
characters are unsupported.
related: vim/vim#18566d7fb4cd2f8
Co-authored-by: Marshall Ward <marshall.ward@gmail.com>
Previously, a comment in a directive block would incorrectly mark
all subsequent lines in the directive block as comment, because the
syn-region did not check the leading indent.
related: vim/vim#185664e9f16dd1e
Co-authored-by: Antony Lee <anntzer.lee@gmail.com>
The leading two dots of a RST directive gets matched by
rstExplicitMarkup group first, and then the directive name and directive
body will be matched by the groups contained in rstDirectives cluster in
order.
The rstExDirective group in rstDiretives matches any RST directives
other than footnote, citation and hyperlink target, therefore admonition
and code block will be matched by rstExDirective. This fix has
rstExDirective contain rstExplicitMarkup so as to enable recursive RST
directives match.
The interpreted texts enclosed in quotes are not highlighted within a
RST directive body, because the rstCruft cluster contains a non-existing
rstInterpretedText group.It should be renamed to
rstInterpretedTextOrHyperlinkReference which is defined in a
DefineInlineMarkup function call.
related: vim/vim#1856647949b4b46
Co-authored-by: Minjie Xu <madjxatw@gmail.com>
Following the approach used in other syntax definitions, add support for
defining the "syntax sync minlines=..." values for rst files in the
users' ~/.vimrc files, to allow the users to adjust that value in case
syntax highlighting stops working for some of the files they edit.
related: vim/vim#18566310082f3cf
Co-authored-by: Dragan Simic <dsimic@manjaro.org>
A doctest block usually spans multiple lines, e.g.
>>> print('this is a Doctest block')
this is a Doctest block
Remove ``oneline`` argument to syntax region as this requirement is not
met. Consequently, also remove ``display`` as the prerequisite (the
syntax region is on a single line) is no longer met.
----
Recognise '>>>' inside doctest blocks
Recognise subsequent '>>>' prompts in doctest blocks, e.g.
>>> print('this is a Doctest block')
this is a Doctest block
>>> print('this is a second Doctest block')
this is a second Doctest block
A doctest block usually spans multiple lines, e.g.
>>> print('this is a Doctest block')
this is a Doctest block
related: vim/vim#185660940465866
Co-authored-by: Kirk Roemer <91125534+kirk-roemer@users.noreply.github.com>
- Column align tags
- Move tags to the same line as the function signature
- Move descriptions to the line below the function signature
- Add missing hyperlinks to builtins in the description text
closes: vim/vim#1847883eb1da19e
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Fix syntax highlighting for def-style Python functions, with their
parameters spanning multiple lines. E.g. the following should match as
valid Python code in Bitbake recipes:
def myFunction(one, two, \
three, four):
pass
For this to work, use the prefix modifier "\_" before the wildcard ".",
to also match newline characters.
closes: vim/vim#185655fe4faa711
Co-authored-by: Martin Schwan <m.schwan@phytec.de>
Problem: CTRL-F and CTRL-B don't work in more prompt
Solution: Make CTRL-F and CTRL-B scroll by a screen down/up
(Bjoern Foersterling)
closes: vim/vim#18545fcf4c435af
Co-authored-by: bfoersterling <bjoern.foersterling@gmail.com>
Suppresses output from the :only command by passing the { silent = true }
modifier to vim.cmd.only(). This prevents unnecessary messages when
setting up the diff layout.
Closes#36167
