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#1460298b12ede31
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
`vim.ui.open` unnecessarily invents a different success/failure
convention. Its return type was changed in 57adf8c6e0, 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`.
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#14620a4c085a3e6
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.
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 }`.
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
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:
While the fold level computation is incremental, the evaluation of the
foldexpr is done on the full buffer. Despite that the foldexpr reads
from the cache, it can take tens of milliseconds for moderately big (10K
lines) buffers.
Solution:
Track the range of lines on which the foldexpr should be evaluated.
Problem: Using xstrlcpy() when the exact length of the string to be
copied is known is not ideal because it requires adding 1 to
the length and an unnecessary strlen().
Solution: Add xmemcpyz() and use it in place of such xstrlcpy() calls.
runtime(bp): fix comment definition in filetype plugin (vim/vim#14594)
I somehow messed up the previous patch, I think a copy-paste error when
creating the file.
Blueprint files have C and C++ style comments, not shell-like '#'
comments.
cee034112d
Co-authored-by: Bruno BELANYI <bruno@belanyi.fr>
Problem:
The use-case for the convenience functions vim.iter.map(),
vim.iter.filter(), vim.iter.totable() is not clear.
Solution:
Drop them for now. We can revisit after 0.10 release.
Problem: runtime(uci): No support for uci file types
(Wu, Zhenyu)
Solution: include basic uci ftplugin and syntax plugins
(Colin Caine)
closes: vim/vim#145754b3fab14db
Co-authored-by: Colin Caine <complaints@cmcaine.co.uk>
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
runtime(java): Support "g:ftplugin_java_source_path" with archived files
Also, document for "g:ftplugin_java_source_path" its current
modification of the local value of the 'path' option.
closes: vim/vim#1457036e667ab83
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
Problem:
We need to establish a pattern for `enable()`.
Solution:
- First `enable()` parameter is always `enable:boolean`.
- Update `vim.diagnostic.enable()`
- Update `vim.lsp.inlay_hint.enable()`.
- It was not released yet, so no deprecation is needed. But to help
HEAD users, it will show an informative error.
- vim.deprecate():
- Improve message when the "removal version" is a *current or older* version.
Problem:
The order of the validation performed by vim.validate() is
unpredictable.
- harder to write reliable tests.
- confusing UX because validation result might return different errors randomly.
Solution:
Iterate the input using `vim.spairs()`.
Future:
Ideally, the caller could provide an "ordered dict".
Problem: filetype: some requirements files are not recognized
Solution: Detect '*-requirements.txt', 'constraints.txt',
'requirements.in', 'requirements/*.txt' and 'requires/*.txt'
as requirements filetype, include pip compiler, include
requirements filetype and syntax plugin
(Wu, Zhenyu, @raimon49)
closes: vim/vim#14379f9f5424d3e
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Co-authored-by: raimon <raimon49@hotmail.com>
runtime(java): Recognise non-ASCII identifiers (vim/vim#14543)
* runtime(java): Recognise non-ASCII identifiers
Also:
- Remove the already commented out and less general in its
definition javaFuncDef alternative.
- Stop recognising some bespoke {p,trace} debugging API.
Non-ASCII identifiers have been supported from the outset
of the Java language.
> An _identifier_ is an unlimited-length sequence of _Java
> letters_ and _Java digits_, the first of which must be a
> Java letter. An identifier cannot have the same spelling
> (Unicode character sequence) as a keyword . . . Boolean
> literal . . . or the null literal . . .
> . . . . . . . .
> Letters and digits may be drawn from the entire Unicode
> character set . . .
> . . . . . . . .
> A Java letter is a character for which the method
> Character.isJavaLetter . . . returns true. A Java
> letter-or-digit is a character for which the method
> Character.isJavaLetterOrDigit . . . returns true.
> . . . . . . . .
> The Java letters include . . . for historical reasons, the
> ASCII underscore (_) . . . and dollar sign ($) . . .
(Separate syntax tests will be written when particular parts
now touched will have been further improved.)
Reference:
https://javaalmanac.io/jdk/1.0/langspec.pdf [§3.8]
* Take on the maintenance of Java filetype and syntax files
4052474a1b
Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
