Problem: Vim9: crash when debugging a function with line continuation.
Solution: Check for a NULL pointer. (closesvim/vim#8521)
303215d60c
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Temp files remain after running tests.
Solution: Delete the right files. (Dominique Pellé, closesvim/vim#8509)
6c72fd51a8
Co-authored-by: Dominique Pelle <dominique.pelle@gmail.com>
Problem: Vim9: breakpoint on "for" does not work.
Solution: Use the right line number in ISN_DEBUG. (closesvim/vim#8486)
6fc0161682
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: debugging lambda does not work.
Solution: Use the compile type of the function when compiling a lambda.
(closesvim/vim#8412)
17d868b8b2
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: breakpoint at a comment line does not work.
Solution: Add the comment line number to the debug instruction.
(closesvim/vim#8429)
8cec9273d2
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: breakpoint in compiled function not always checked.
Solution: Check for breakpoint when calling compiled function from compiled
function.
2ac4b2536a
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: cannot set breakpoint in compiled function.
Solution: Check for breakpoint when calling a function.
4f8f54280f
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: debugger shows too many lines.
Solution: Truncate at a comment, "enddef", etc. (closesvim/vim#8392)
59b50c3bee
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim: when debugging only the first line of a command using line
continuation is displayed.
Solution: Find the next command and concatenate lines until that one.
(closesvim/vim#8392)
4cea536bdf
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: cannot get argument values during debugging.
Solution: Lookup names in the list of arguments. Put debug instruction
halfway for command.
6bc30b05e6
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Vim9: when debugging cannot inspect local variables.
Solution: Make local variables available when debugging.
b69c6fb7b4
Co-authored-by: Bram Moolenaar <Bram@vim.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>
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
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: CI: test_termdebug may still fail
Solution: use term_wait() to make it more robust
closes: vim/vim#13529fdbadea4b6
Co-authored-by: shane.xb.qian <shane.qian@foxmail.com>
Problem: CI: test_termdebug fails
Solution: only test for a changed winlayout, if the window
width actually changed
Also, include an unrelated comment (which doesn't warrant its own patch
number)
305127f9f2
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Terminal test for current directory not used on FreeBSD.
Solution: Make it work on FreeBSD. (Ozaki Kiichi, closesvim/vim#9516) Add
TermWait() inside Run_shell_in_terminal() as a generic solution.
ced2b38a56
Co-authored-by: Bram Moolenaar <Bram@vim.org>
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>
Problem: It is not easy to restore saved mappings.
Solution: Make mapset() accept a dict argument. (Ernie Rael, closesvim/vim#10295)
51d04d16f2
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: Can only get a list of mappings.
Solution: Add the optional {abbr} argument. (Ernie Rael, closesvim/vim#10277)
Rename to maplist(). Rename test file.
09661203ec
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: Not simple programmatic way to find a specific mapping.
Solution: Add getmappings(). (Ernie Rael, closesvim/vim#10273)
659c240cf7
Co-authored-by: Ernie Rael <errael@raelity.com>
Problem: maparg() does not indicate the type of script where it was defined.
Solution: Add "scriptversion".
a9528b39a6
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: still some issues with term_debug test
Solution: Use WaitForAssert()
closes: vim/vim#1293685c3a5bc26
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: No tests for the termdebug plugin
Solution: Add some simple tests for the termdebug plugin
closes: vim/vim#1292758f39d89a8
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: statusline may look different than expected
Solution: do not check for highlighting of stl and stlnc characters
statusline fillchar may be different than expected
If the highlighting group for the statusline for the current window
|hl-StatusLine| or the non-current window |hl-StatusLineNC| are cleared
(or do not differ from each other), than Vim will use the hard-coded
fallback values '^' (for the non-current windows) or '=' (for the
current window). I believe this was done, to make sure the statusline
will always be visible and be distinguishable from the rest of the
window.
However, this may be unexpected, if a user explicitly defined those
fillchar characters just to notice that those values are then not used
by Vim.
So, let's assume users know what they are doing and just always return
the configured stl and stlnc values. And if they want the statusline to
be non-distinguishable from the rest of the window space, so be it. It
is their responsibility and Vim shall not know better what to use.
fixes: vim/vim#13366closes: vim/vim#134886a650bf696
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: No way to have extmarks automatically removed when the range it
is attached to is deleted.
Solution: Add new 'invalidate' property that will hide a mark when the
entirety of its range is deleted. When "undo_restore" is set
to false, delete the mark from the buffer instead.
Problem: tests: failure in test_arabic
Solution: adjust the test for the changed arabic keymap
2a94e98792
Co-authored-by: Christian Brabandt <cb@256bit.org>
It is a design goal of extmarks that they allow precise tracking
of changes across undo/redo, including restore the exact positions
after a do/undo or undo/redo cycle. However this behavior is not useful
for all usecases. Many plugins won't keep marks around for long after
text changes, but uses them more like a cache until some external source
(like LSP semantic highlights) has fully updated to changed text and
then will explicitly readjust/replace extmarks as needed.
Add a "undo_restore" flag which is true by default (matches existing
behavior) but can be set to false to opt-out of this behavior.
Delete dead u_extmark_set() code.
Problem: complete_info() skips entries with 'noselect'
Solution: Check, if first entry is at original text state
Unfortunately, Commit daef8c74375141974d61b85199b383017644978c
introduced a regression, that when ':set completeopt+=noselect' is set
and no completion item has been selected yet, it did not fill the
complete_info['items'] list.
This happened, because the current match item did not have the
CP_ORIGINAL_TEXT flag set and then the cp->prev pointer did point to the
original flag item, which caused the following while loop to not being
run but being skipped instead.
So when the 'noselect' is set, only start with to the previous selection
item, if the initial completion item has the CP_ORIGINAL_TEXT flag set,
else use the 2nd previous item instead.
fixes: vim/vim#13451closes: vim/vim#1345257f9ce1a09
Co-authored-by: Christian Brabandt <cb@256bit.org>
