Problem:
On Windows, "gf" fails on a filepath that has a line:column suffix.
Example:
E447: Can't find file "src/app/core/services/identity/identity.service.ts:64:23"
Solution:
- Remove ":" from 'isfname' on Windows. Colon is not a valid filename
character (except for the drive-letter).
- Handle drive letters specially in file_name_in_line().
Fixes#25160
This finalizes the long running refactor from the old TUI-focused grid
implementation where text-drawing cursor was not separated from the
visible cursor.
Still, the pattern of setting cursor position together with updating a
line was convenient. Introduce grid_line_cursor_goto() to still allow
this but now being explicit about it.
Only having batched drawing functions makes code involving drawing
a bit longer. But it is better to be explicit, and this highlights
cases where multiple small redraws can be grouped together. This was the
case for most of the changed places (messages, lastline, and :intro)
Problem:
The swapfile "E325: ATTENTION" dialog is displayed when editing a file
already open in another (running) Nvim. Usually this behavior is
annoying and irrelevant:
- "Recover" and the other options ("Open readonly", "Quit", "Abort") are
almost never wanted.
- swapfiles are less relevant for "multi-Nvim" since 'autoread' is
enabled by default.
- Even less relevant if user enables 'autowrite'.
Solution:
Define a default SwapExists handler which does the following:
1. If the swapfile is owned by a running Nvim process, automatically
chooses "(E)dit anyway" (caveat: this creates a new, extra swapfile,
which is mostly harmless and ignored except by `:recover` or `nvim -r`.
2. Shows a 1-line "ignoring swapfile..." message.
3. Users can disable the default SwapExists handler via `autocmd! nvim_swapfile`.
msg_puts_display was more complex than necessary in nvim, as in
nvim, it no longer talks directly with a terminal.
In particular we don't need to scroll the grid before emiting the last
char. The TUI already takes care of things like that, for terminals
where it matters.
Problem: Visual highlight is inconsistent on a folded line with
treesitter foldtext.
Solution: Don't added Folded highlight as it is already in background.
The haskell-language-server supports resolve only for a subset of code
actions. For many code actions trying to resolve the `edit` property
results in an error, but the unresolved action already contains a
command that can be executed without issue.
The protocol specification is unfortunately a bit vague about this,
and what the haskell-language-server does seems to be valid.
Example:
newtype Dummy = Dummy Int
instance Num Dummy where
Triggering code actions on "Num Dummy" and choosing "Add placeholders
for all missing methods" resulted in:
-32601: No plugin enabled for SMethod_CodeActionResolve, potentially available: explicit-fields, importLens, hlint, overloaded-record-dot
With this change it will insert the missing methods:
instance Num Dummy where
(+) = _
(-) = _
(*) = _
negate = _
abs = _
signum = _
fromInteger = _
Problem:
NVIM_APPNAME does not allow path separators in the name, so relative
paths can't be used:
NVIM_APPNAME="neovim-configs/first-config" nvim
NVIM_APPNAME="neovim-configs/second-config" nvim
Solution:
Let NVIM_APPNAME be a relative path. Absolute paths are not supported.
fix#23056fix#24966
Problem: TextChanged does not trigger after TextChangedI.
Solution: Store the tick separately for TextChangedI. (Christian Brabandt,
closesvim/vim#8968, closesvim/vim#8932)
db3b44640d
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
Some steps in :Tutor don't work on Windows.
Solution:
Add support for `{unix:...,win:...}` format and transform the Tutor contents
depending on the platform.
Fix https://github.com/neovim/neovim/issues/24166
Problem:
Crash from:
set cmdheight=0 redrawdebug=invalid
resize -1
Solution:
Do not invalidate first `p_ch` `msg_grid` rows in `update_screen` when
scrolling the screen down after displaying a message, because they may
be used later for drawing cmdline.
Fixes#22154
This is incorrect in the following scenario:
1. The language tree is Lua > Vim > Lua.
2. An edit simultaneously wipes out the `_regions` of all nodes, while
taking the Vim injection off-screen.
3. The Vim injection is not re-parsed, so the child Lua `_regions` is
still `nil`.
4. The child Lua is assumed, incorrectly, to occupy the whole document.
5. This causes the injections to be parsed again, resulting in Lua > Vim
> Lua > Vim.
6. Now, by the same process, Vim ends up with its range assumed over the
whole document. Now the parse is broken and results in broken
highlighting and poor performance.
It should be fine to instead treat an unparsed node as occupying
nothing (i.e. effectively non-existent). Since, either:
- The parent was just parsed, hence defining `_regions`
- The parent was not just parsed, in which case this node doesn't need
to be parsed either.
Also, the name `has_regions` is confusing; it seems to simply
mean the opposite of "root" or "full_document". However, this PR does
not touch it.
