| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
Intersection rejects ranges whose inclusive end equals the other start,
discarding a shared character and even a one-character self-intersection.
Solution:
Use strict comparisons when checking inclusive ends for non-overlap.
Cover two ranges that share a single character.
AI-assisted
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
Converting an exclusive end at column zero moves to the preceding row
but calculates the inclusive column from the original row's text.
Solution:
Read the preceding line after decrementing the row. Cover adjacent lines
with unequal lengths.
AI-assisted
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- call-non-callable
- missing-fields
- redefined-label
- redefined-local
- undefined-field
- unreachable-code
Promote redefined-local and unreachable-code to warnings.
Fix DOS line-ending handling for multiline semantic tokens, and support
intersection types in the help parser.
AI-assisted
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: LuaLS struggles with the generics used in Nvim's runtime,
requiring broad diagnostic suppressions. Indexing is also slow.
Solution: Use EmmyLua for type checks in the build and CI. It offers
more sophisticated type checking, substantially better support for
generics, and much better flow analysis.
Correct the affected annotations. Use `@internal`, supported directly by
EmmyLua, instead of `@nodoc` for shared internal declarations, and
support it in the help parser.
AI-assisted
|
| |
|
| |
Allow plugins to set the human-readable fields.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
Our documentation is incomplete or inconsistent in several ways:
- Some public APIs lack corresponding validators.
- Some public APIs lack usage examples.
- The meaning of some return values or parameters is not clearly explained.
Solution:
Add the missing validators, examples, and clarifications.
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
- To share logic, creating a `vim.Range` currently creates two `vim.Pos` values
as intermediates, which causes unnecessary table allocations.
- `pos.lua` and `range.lua` contain some overlapping logic.
Solution:
Add `vim.pos._util`, a module for handling
positions represented directly by `row` and `col`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
- A window can only have one cursor, ranges selected by the cursor are typically
obtained by marks like ">" and "<", instead of calling get_cursor() twice.
- `vim.Range` is described as end-exclusive,
but the current `range.cursor()`/`range:to_cursor()` are end-inclusive.
- Conversion between `vim.Range` and mark-indexed range can be done by
`range.mark()`/`range:to_mark()`
Solution:
Remove `range.cursor()` and `range:to_cursor()`,
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Problem:
Ranges represented by marks are usually end-inclusive,
but the range utilities we provided are end-exclusive.
Solution:
Add pos:to_mark(), pos.mark(), range:to_mark(), and range.mark().
|
| |
|
|
|
|
|
|
| |
Problem:
- Empty ranges have different `<`, `<=`, `has` and `intersect` semantics compared to regular ranges.
- `to_inclusive_pos` assumes that the end position of a range is exclusive, which is not true for empty ranges
Solution:
Special case empty ranges in these operations.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
AI-assisted: Codex
|
| |
|
|
| |
This reverts commit c530fd8e752607f57b83854b74b029eabe8d57c6.
|
| | |
|
| |
|
| |
new() only supports nargs=5 or nargs=2, but this was passing 4 args.
|
| |
|
|
|
|
|
| |
Problem:
`vim.Range` and `vim.Pos` have signature mismatches on the docs of some functions.
Solution:
Split the "module" functions from the "class" functions (just like it's done in other modules like `vim.version`) and regenerate the docs.
|
| |
|
|
|
|
|
| |
Problem: `buf` is optional even though its needed to perform conversions
and the ordering of `(buf, row, col)` is not consistent.
Solution: make `buf` mandatory on `vim.range` and `vim.pos` and enforce
the `buf, row, col` ordering
|
| |
|
|
|
|
|
|
|
| |
Close #38431
Close #38521
Close #38530
Co-authored-by: tayheau <thopsore@pasteur.fr>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Olivia Kinnear <git@superatomic.dev>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Using nested `vim.Pos` objects to represent each `vim.Range` object
requires 3 tables for each `vim.Range`, which may be undesirable in
performance critical code. Using key-value tables performs worse than
using array-like tables (lists).
Solution:
Use array-like indices for the internal fields of both `vim.Pos` and
`vim.Range` objects. Use a metatable to allow users to access them like
if they were key-value tables.
---
Problem:
The `vim.Pos` conversion interface for `extmark` indexing does not take
into account the difference in how a position on top of a newline is
represented in `vim.Pos` and `extmark`.
- `vim.Pos`: for a newline at the end of row `n`, `row` takes the value
`n + 1` and `col` takes the value `0`.
- `extmark`: for a newline at the end of for `n`, `row` takes the value
`n` and `col` takes the value `#row_text`.
Solution:
Handle this in the `extmark` interface.
---
Problem:
Not all `to_xxx` interfaces have wrapping objects like `to_lsp`.
Solution:
Return unwrapped values in `to_xxx` interfaces where it makes sense.
Accept unwrapped values in "from" interfaces where it makes sense.
---
Problem:
`start` and `end` positions have different semantics, so they can't be
compared. `vim.Range` relies on comparing the `end` and `start` of two
ranges to decide which one is greater, which doesn't work as expected
because this of the different semantics.
For example, for the ranges:
local a = {
start = { row = 0, col = 22, },
end_ = { row = 0, col = 24, },
}
local b = {
start = { row = 0, col = 17, },
end_ = { row = 0, col = 22, },
}
in this code:
local foo, bar = "foo", "bar"
-- |---||-|
-- b a
The range `b` is smaller than the range `a`, but the current
implementation compares `b._end` (`col = 22`) and `a.start` (`col = 22`)
and concludes that, since `b.col` is not smaller than `a.col`, `b`
should be greater than `a`.
Solution:
- Use a `to_inclusive_pos` to normalize end positions inside of
`vim.Range` whenever a comparison between a start and an end position
is necessary.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* feat(lua): `Range:is_empty()` to check vim.range emptiness
* fix(lsp): don't overlay insertion-style inline completions
**Problem:** Some servers commonly respond with an empty inline
completion range which acts as a position where text should be inserted.
However, the inline completion module assumes that all responses with a
range are deletions + insertions that thus require an `overlay` display
style. This causes an incorrect preview, because the virtual text should
have the `inline` display style (to reflect that this is purely an
insertion).
**Solution:** Only use `overlay` for non-empty replacement ranges.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Close #34938
Close #35030
Close #35233
Close #35259
Close #35290
Close #35433
Close #35541
Close #35766
Close #35792
Co-authored-by: huylg <45591413+huylg@users.noreply.github.com>
Co-authored-by: Jason Del Ponte <961963+jasdel@users.noreply.github.com>
Co-authored-by: sooriya <74165167+thuvasooriya@users.noreply.github.com>
Co-authored-by: Andrew Braxton <andrewcbraxton@gmail.com>
Co-authored-by: Enric Calabuig <enric.calabuig@gmail.com>
Co-authored-by: Augusto César Dias <augusto.c.dias@gmail.com>
Co-authored-by: David Sierra DiazGranados <davidsierradz@gmail.com>
Co-authored-by: Stepan Nikitin <90522882+vectravox@users.noreply.github.com>
Co-authored-by: Emilien Breton <bricktech2000@gmail.com>
|
| | |
|
| | |
|
| |
|
