**Problems:**
- `vim.treesitter.language.inspect()` returns duplicate
symbol names, sometimes up to 6 of one kind in the case of `markdown`
- The list-like `symbols` table can have holes and is thus not even a
valid msgpack table anyway, mentioned in a test
**Solution:** Return symbols as a map, rather than a list, where field
names are the names of the symbol. The boolean value associated with the
field encodes whether or not the symbol is named.
Note that anonymous nodes are surrounded with double quotes (`"`) to
prevent potential collisions with named counterparts that have the same
identifier.
This commit also marks `child_containing_descendant()` as deprecated
(per upstream's documentation), and uses `child_with_descendant()` in
its place. Minimum required tree-sitter version will now be `0.24`.
Problem: on `CompleteDone` cursor can jump to the end of line instead of
the end of the completed word.
Solution: remove only inserted word for snippet expansion instead of everything
until eol.
Fixes#30656
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: Currently completion attribute hl_group is combined with
all items, which is redundant and confusing with kind_hlgroup
Solution: Renamed to abbr_hlgroup and combine it only with the abbr item
(glepnir).
closes: vim/vim#158180fe17f8ffb
Co-authored-by: glepnir <glephunter@gmail.com>
The syntax script allowed for single backslash escapes like this
"string\""
But did not accommodate for the uncommon case:
"<key>\\"
Let's fix this by also skipping over double backslashes in the
skillString region.
closes: vim/vim#15832cb1d1dcc87
Co-authored-by: Simão Afonso @ Powertools Tech <simao.afonso@powertools-tech.com>
Problem: current command completion is a bit limited
Solution: Add the shellcmdline completion type and getmdcomplpat()
function (Ruslan Russkikh).
closes: vim/vim#158230407d621bb
Co-authored-by: Ruslan Russkikh <dvrussk@yandex.ru>
Problem:
In h2 headings, the first tag points to an invalid anchor. This used to
work but regressed a few months ago, possibly related to
ceea6898a8.
Solution:
- Simplify the logic, don't try to be clever:
- Always use to_heading_tag() for the h2 `id`.
- Also:
- Render tags as `<span>`, because `<code>` is unnecessary and doesn't
look great in headings.
- In the main h1, use "foo.txt" as the anchor `name` (rarely used),
prefer the next found tag for the `href`.
Problem: No test for patches 6.2.418 and 7.3.489
Solution: Add a test. Fix some whitespace problems in test_mapping.vim.
Document the behavior (zeertzjq).
closes: vim/vim#158155df3cb2898
Problem:
tagfunc failed in a weird buffer (either a directory or some other
non-file buffer, I don't remember):
E987: Invalid return value from tagfunc
E5108: Error executing lua …/runtime/lua/vim/lsp/util.lua:311: EISDIR: illegal operation on a directory
stack traceback:
at this line:
local data = assert(uv.fs_read(fd, stat.size, 0))
Solution:
Check for directory.
Problem: 'cedit', 'termwinkey' and 'wildchar' may not be parsed
correctly
Solution: improve string_to_key() function in option.c
(Milly)
- Problem: `^@` raises an error.
Solution: Store as `<Nul>`.
- Problem: `<t_xx` does not raise an error.
Solution: Raise an error if closing `>` is missing.
- Problem: Single `<` or `^` raises an error. It is inconvenient for users.
Solution: They are stored as a single character.
closes: vim/vim#15811a9c6f90918
Co-authored-by: Milly <milly.ca@gmail.com>
Problem:
- Some servers like LuaLS add unwanted blank lines after multiline
`@param` description.
- List items do not wrap nicely.
Solution:
- When rendering the LSP doc hover, remove blank lines in each `@param`
or `@return`.
- But ensure exactly one empty line before each.
- Set 'breakindent'.
The current LspAttach example shows setting options which are already
set by default. We should expect that users are going to copy-paste
these examples, so we shouldn't use examples that are superfluous and
unnecessary.
Problem: `runtime/tools/emoji_list.vim` is a Lua script masquerading as
Vimscript, which is unnecessary now that `:source` works for Lua files.
Solution: Remove Vimscript wrapper.
With "g:markdown_fenced_languages" defined and "java" added
to its list, a circular dependency between the Markdown and
Java syntax files will be made. To break it, no Markdown
documentation comments will be recognised in fenced blocks
in Markdown files; in order to view Java source files,
"java" must be removed from "g:markdown_fenced_languages",
and this task can be automated as follows.
1) Add to "~/.after/ftplugin/java.vim":
------------------------------------------------------------
if exists("g:markdown_fenced_languages") &&
\ !(exists("g:java_ignore_javadoc") ||
\ exists("g:java_ignore_markdown"))
let s:idx = index(g:markdown_fenced_languages, 'java')
if s:idx > -1
call remove(g:markdown_fenced_languages, s:idx)
endif
unlet s:idx
endif
------------------------------------------------------------
2) Optionally add to "~/.after/ftplugin/markdown.vim":
------------------------------------------------------------
if exists("g:markdown_fenced_languages") &&
\ index(g:markdown_fenced_languages, 'java') < 0
call add(g:markdown_fenced_languages, 'java')
endif
------------------------------------------------------------
(Make sure that the above snippets appear in the files under
the "ftplugin" NOT "syntax" directory.)
Finally, unless the new version of the syntax file is made
available from "$VIMRUNTIME" (and from "~/.vim/syntax" if
necessary), OTHER discoverable file versions will be used
whose behaviour may interfere with this fix.
related: vim/vim#15740closes: vim/vim#1579660310a4b26
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
Some commands don't accept "count" and only work with "range". It's not
clear why. The issue is tracked at [1], but this is a workaround for
now.
[1]: https://github.com/neovim/neovim/issues/30641
Problem: Lua accessors for
- global, local, and special variables (`vim.{g,t,w,b,v}.*`), and
- options (`vim.{o,bo,wo,opt,opt_local,opt_global}.*`),
do not have command-line completion, unlike their vimscript counterparts
(e.g., `g:`, `b:`, `:set`, `:setlocal`, `:call <fn>`, etc.).
Completion for vimscript functions (`vim.fn.*`) is incomplete and does
not list all the available functions.
Solution: Implement completion for vimscript function, variable and
option accessors in `vim._expand_pat` through:
- `getcompletion()` for variable and vimscript function accessors, and
- `nvim_get_all_options_info()` for option accessors.
Note/Remark:
- Short names for options are yet to be implemented.
- Completions for accessors with handles (e.g. `vim.b[0]`, `vim.wo[0]`)
are also yet to be implemented, and are left as future work, which
involves some refactoring of options.
- For performance reasons, we may want to introduce caching for
completing options, but this is not considered at this time since the
number of the available options is not very big (only ~350) and Lua
completion for option accessors appears to be pretty fast.
- Can we have a more "general" framework for customizing completions?
In the future, we may want to improve the implementation by moving the
core logic for generating completion candidates to each accessor (or
its metatable) or through some central interface, rather than writing
all the accessor-specific completion implementations in a single
function: `vim._expand_pat`.
