| Commit message (Collapse) | Author | Age |
... | |
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
- crn for rename
- crr for code actions
- gr for references
- <C-S> (in Insert mode) for signature help
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem:
vim.iter has both `rfind()` and various `*back()` methods, which work
in "reverse" or "backwards" order. It's inconsistent to have both kinds
of names, and "back" is fairly uncommon (rust) compared to python
(rfind, rstrip, rsplit, …).
Solution:
- Remove `nthback()` and let `nth()` take a negative index.
- Because `rnth()` looks pretty obscure, and because it's intuitive
for a function named `nth()` to take negative indexes.
- Rename `xxback()` methods to `rxx()`.
- This informally groups the "list-iterator" functions under a common
`r` prefix, which helps discoverability.
- Rename `peekback()` to `pop()`, in duality with the existing `peek`.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes regression introduced in #28030
If an LSP server is restarted, then the associated `nvim_buf_attach`
call will not detach if no buffer changes are sent between the client
stopping and a new one being created. This leads to `nvim_buf_attach`
being called multiple times for the same buffer, which then leads to
changetracking sending duplicate requests to the server (one per
attach).
To solve this, introduce separate tracking (client agnostic) on which
buffers have had calls to `nvim_buf_attach`.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
vim.notify cannot be suppressed and it is not always necessary to
display a visible warning to the user if the RPC process fails to start.
For instance, a user may have the same LSP configuration across systems,
some of which may not have all of the LSP server executables installed.
In that case, the user receives a notification every time a file is
opened that they cannot suppress.
Instead of using vim.notify in vim.lsp.rpc, propagate a normal error up
through the call stack and use vim.notify in vim.lsp.start() only if
the "silent" option is not set.
This also updates lsp.start_client() to return an error message as its
second return value if an error occurred, rather than calling vim.notify
directly. Callers of lsp.start_client() will need to update call sites
appropriately if they wish to report errors to the user (or even better,
switch to vim.lsp.start).
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
`handle:write(msg)` can fail if the socket is not yet connected to the
server.
Should address https://github.com/neovim/neovim/pull/28398#issuecomment-2078152491
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: ops.c code uses too many strlen() calls
Solution: Refactor code and remove more strlen() calls
(John Marriott)
closes: vim/vim#14598
https://github.com/vim/vim/commit/38b9f45253f582ab63174376e321092f8a9a7808
Co-authored-by: John Marriott <basilisk@internode.on.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
runtime(asm): fix undefined variable in indent plugin
It's an indent script, so we need to set the b:undo_indent variable
instead of the b:undo_ftplugin var.
fixes: vim/vim#14602
https://github.com/vim/vim/commit/98b12ede31754071f36fb7a73324456c1ee7b89c
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | |
|
| |
| |
| |
| |
| | |
When the "severity" option is nil, vim.diagnostic.goto_next() and
vim.diagnostic.goto_prev() jump to the next diagnostic with the highest
severity.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem:
`vim.ui.open` unnecessarily invents a different success/failure
convention. Its return type was changed in 57adf8c6e01d, so we might as
well change it to have a more conventional form.
Solution:
Change the signature to use the `pcall` convention of `status, result`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts a large portion of
2c1e8f7e96926f70151d737ea32f1e6ff3589263.
The conclusion from that commit is incorrect: local builds are not
used/updated correctly so much as it's not used at all. Instead the
build will always use `master` branch rather than the current files.
|
| |\
| | |
| | | |
fix(lua): vim.fn.has('nvim-0.10') in fast context, used by vim.deprecate
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
runtime(java): Improve the recognition of the "style" method declarations
- Request the new regexp engine (v7.3.970) for [:upper:] and
[:lower:].
- Recognise declarations of in-line annotated methods.
- Recognise declarations of _strictfp_ methods.
- Establish partial order for method modifiers as shown in
the MethodModifier production; namely, _public_ and
friends should be written the leftmost, possibly followed
by _abstract_ or _default_, or possibly followed by other
modifiers.
- Stop looking for parameterisable primitive types (void<?>,
int<Object>, etc., are malformed).
- Stop looking for arrays of _void_.
- Acknowledge the prevailing convention for method names to
begin with a small letter and for class/interface names to
begin with a capital letter; and, therefore, desist from
claiming declarations of enum constants and constructors
with javaFuncDef.
Rationale:
+ Constructor is distinct from method:
* its (overloaded) name is not arbitrary;
* its return type is implicit;
* its _throws_ clause depends on indirect vagaries of
instance (variable) initialisers;
* its invocation makes other constructors of its type
hierarchy invoked one by one, concluding with the
primordial constructor;
* its explicit invocation, via _this_ or _super_, can
only appear as the first statement in a constructor
(not anymore, see JEP 447); else, its _super_ call
cannot appear in constructors of _record_ or _enum_;
and neither invocation is allowed for the primordial
constructor;
* it is not a member of its class, like initialisers,
and is never inherited;
* it is never _abstract_ or _native_.
+ Constructor declarations tend to be few in number and
merit visual recognition from method declarations.
+ Enum constants define a fixed set of type instances
and more resemble class variable initialisers.
Note that the code duplicated for @javaFuncParams is written
keeping in mind for g:java_highlight_functions a pending 3rd
variant, which would require none of the :syn-cluster added
groups.
closes: vim/vim#14620
https://github.com/vim/vim/commit/a4c085a3e607bd01d34e1db600b6460fc35fb0a3
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | | |
vim.fs.root() is a function for finding a project root relative to a
buffer using one or more "root markers". This is useful for LSP and
could be useful for other "projects" designs, as well as for any plugins
which work with a "projects" concept.
|
| | |
| | |
| | | |
\
|
| | | |
|
| |/
| |
| |
| |
| |
| | |
Instead of adding all diagnostics matching lnum filters to a table, and
then copying that table to another table while applying the severity
filter, this changes the flow to only add diagnostics matching both
filters in the first pass.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: Vim9: missing :endif not reported when using :windo.
Solution: Pass a getline function to do_cmdline(). (closes vim/vim#7650)
https://github.com/vim/vim/commit/9567efa1b4a41baca9b2266f5903d5dda7ad1e88
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| |
| |
| |
| | |
Both methods had pretty much the same documentation and shared the
implementation.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Specifically, functions that are run in the context of the test runner
are put in module `test/testutil.lua` while the functions that are run
in the context of the test session are put in
`test/functional/testnvim.lua`.
Closes https://github.com/neovim/neovim/issues/27004.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: `vim.deprecate()` can be relatively significantly slower than
the deprecated function in "Nvim" plugin.
Solution: Optimize checks for "Nvim" plugin. This also results into not
distinguishing "xxx-dev" and "xxx" versions when doing checks, which
is essentially covered by the deprecation logic itself.
With this rewrite I get the times from #28459: `{ 0.024827, 0.003797, 0.002024, 0.001774, 0.001703 }`.
For quicker reference:
- On current Nightly it is something like `{ 3.72243, 0.918169, 0.968143, 0.763256, 0.783424 }`.
- On 0.9.5: `{ 0.002955, 0.000361, 0.000281, 0.000251, 0.00019 }`.
|
| |
| |
| |
| |
| |
| |
| |
| | |
#28273
Problem:
vim.diagnostic.get(…,{lnum=…}) does not match multi-line diagnostics.
Solution: add end_lnum support.
|
| |
| |
| |
| |
| | |
Problem: when diagnostic have a range of line, open_float not work.
Solution: filter diagnostic by line number range.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: filetype: ondir files are not recognized
Solution: Detect '.ondirrc' as ondir filetype
(Jon Parise)
closes: vim/vim#14604
https://github.com/vim/vim/commit/ea999037a41292b3d3e00700a87a82fe5d2c12b2
Co-authored-by: Jon Parise <jon@indelible.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: tests: test_vim9_builtin is a bit slow
Solution: source tests from a buffer instead of
writing and sourcing a file (Yegappan Lakshmanan)
closes: vim/vim#14614
https://github.com/vim/vim/commit/22697b6179e38f3d321b1495ef17f06031a9c8f1
N/A patch:
vim-patch:9.1.0299: Vim9: return type not set for a lambda assigned to script var
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
runtime(doc): update documentation
closes: vim/vim#14616
https://github.com/vim/vim/commit/f7a38650eaf6dd4612fc31f85b6f0d4c6e06567f
Co-authored-by: RestorerZ <restorer@mail2k.ru>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: Crash when typing many keys with D- modifier (after 9.1.0227).
Solution: Don't treat a 0x80 byte inside a special sequence as the start
of a special sequence (zeertzjq).
closes: vim/vim#14613
https://github.com/vim/vim/commit/6b13e3d4e46393b3a35eed7c27ae020bcbd46a9b
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
**Problems**
When launching Neovim on Terminal.app on macOS (Apple Terminal),
it briefly shows like
`p$qm+q5463;524742;73657472676266;73657472676262$qm` in orange
background color partially on the screen.
**Solution**
Since Terminal.app seems not supporting DECRQM and DECRQSS queries,
calling `tui_request_term_mode` and `tui_query_extended_underline`
caused this unexpected output.
Therefore, if we know it's Apple Terminal (when `nsterm` is `true`),
don't call these checks.
Tested on Terminal.app (2.14, 453) on macOS 14.4.1.
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Gregory Anders <greg@gpanders.com>
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(#28429)
Problem: Page scrolling does not always place the cursor at the top or
bottom of the window (Mathias Rav)
Solution: Place the cursor at the top or bottom of the window.
(Luuk van Baal)
https://github.com/vim/vim/commit/4b6b0c4024df08dd8ce49dff3c76356ff81190c4
|
| | |
|
| |\
| | |
| | | |
fix(float): wrong position when bufpos is out of range
|
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: when lnum in bufpos is out of range the position of float is wired.
Solution: avoid the height value out of buffer line range.
|
| | |
| | |
| | |
| | |
| | |
| | | |
TODO:
FUNC_API_REMOTE_ONLY APIs such as `nvim_ui_*` cannot (yet) be used in
`nvim_exec_lua`. We can change FUNC_API_REMOTE_ONLY to allow
Vimscript/Lua to pass an explicit `channel_id`. #28437
|
| | |
| | |
| | | |
forgot some changes in 9912a4c81b0856200f44a38e99d38eae44cef5c9
|
| | | |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
ref https://github.com/neovim/neovim/issues/19596
FAILED test/functional/plugin/health_spec.lua @ 37: :checkhealth completions can be listed via getcompletion()
test/functional/plugin/health_spec.lua:40: Expected objects to be the same.
Passed in:
(string) 'provider.node'
Expected:
(string) 'provider.clipboard'
stack traceback:
test/functional/plugin/health_spec.lua:40: in function <test/functional/plugin/health_spec.lua:37>
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem:
Besides being redundant with vim.iter():flatten(), `tbl_flatten` has
these problems:
- Has `tbl_` prefix but only accepts lists.
- Discards some results! Compare the following:
- iter.flatten():
```
vim.iter({1, { { a = 2 } }, { 3 } }):flatten():totable()
```
- tbl_flatten:
```
vim.tbl_flatten({1, { { a = 2 } }, { 3 } })
```
Solution:
Deprecate tbl_flatten.
Note:
iter:flatten() currently fails ("flatten() requires a list-like table")
on this code from gen_lsp.lua:
local anonym = vim.iter({ -- remove nil
anonymous_num > 1 and '' or nil,
'---@class ' .. anonymous_classname,
}):flatten():totable()
Should we enhance :flatten() to work for arrays?
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: tests: test_winfixbuf is a bit slow
Solution: use defer if possible, reset hidden option, use --not-a-term
when starting Vim using system() (Yegappan Lakshmanan)
closes: vim/vim#14611
https://github.com/vim/vim/commit/4baf908d60e526737090701048a09aa474fde73d
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
runtime(astro): Add filetype, syntax and indent plugin
related: vim/vim#14558
closes: vim/vim#14561
ported from: https://github.com/wuelnerdotexe/vim-astro
https://github.com/vim/vim/commit/d3ff129ce8c68770c47d72ab3f30a21c19530eee
Co-authored-by: Philip H <47042125+pheiduck@users.noreply.github.com>
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tbl_isarray was not released yet, so it will not go through
a deprecation cycle.
ref #24572
|
| |/ /
| | |
| | |
| | | |
ref #24572
|