As this message is literally drawn on top of the EOB area of the first
window, the simple solution is to just draw the message on top of the
grid of the first window.
We still want #24764 (msg_intro event) but now only for ext_messages.
Problem: The ext_cmdline cursor position on the screen seems to rely on
an implicit assumption that the event listener implements a
cmdline window that is made the current window which is
problematic (e.g. breaks 'incsearch' in the actual current
window).
Solution: Remove this assumption and allow nvim_win_set_cursor() to move
the cursor on the screen to a non-current window (previous
commit).
Problem: Cursor position set by nvim_win_set_cursor() is not reflected
on the screen when followed by a blocking call like getchar().
Solution: Immediately update the cursor position on the grid.
Problem: no overflow check for string formatting
Solution: Check message formatting function for overflow.
(Chris van Willegen)
closes: vim/vim#13799c35fc03dbd
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
Problem: Cursor pos wrong when double-width chars are concealed.
Solution: Advance one more virtual column for a double-width char.
Run some tests with both 'wrap' and 'nowrap' (zeertzjq).
closes: vim/vim#14197010e1539d6
Problem:
CursorColumn highlight behavior is inconsistent with 'virtualedit' set:
- If cursor is on the text, CursorColumn is not shown.
- If cursor is after end of line, CursorColumn is shown.
Solution:
Don't shown CursorColumn on current line if cursor is after end of line.
Vim doesn't have this problem because in most cases it uses the code
path for drawing buffer text when CursorColumn highlight is needed.
Instead of randomly disappearing because some random event might have
caused mid_start or bot_scroll_start to randomly take a low value, treat
intro message as a _first class stateful_ thing.
This means that intro message will kept being _redrawn_ as long as we
are in the state it should be shown. This also includes screen resizes.
you will not lose the intro message because there was a delay in
detecting terminal features.
runtime(mswin): still another clipboard_working test
Commit 760f664213dea9a300454992ba1589f4601d622f missed to revert back
another test for `if has('clipboard_working')`
So change the remaining check around the inoremap <c-v> mappings.
fixesvim/vim#1419545da32964d
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(mswin): revert back the check for clipboard_working support
Commit d9ebd46bd090c598adc82e6 changed the condition to
check if the clipboard is available from:
```
has('clipboard')
```
to
```
has('clipboard_working')
```
Assuming that is the more accurate test because even when clipboard
support is enabled at compile time it may not be actually working (e.g.
if no X11 environment is available, or when working on a remote server).
However it seems that condition does not evaluate to true, when the GUI
has not been started up yet (and there was no X11 Connection yet possible).
So let's just revert back the check to `has('clipboard')`, since that
has been proven to be working well enough.
related: vim/vim#13809760f664213
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Coverity reports dead code.
Solution: Remove the dead code. Also fix a mistake in ml_get_pos_len()
and update some comments (zeertzjq).
closes: vim/vim#141898c55d60658
Problem: More code can use ml_get_buf_len() instead of STRLEN().
Solution: Change more STRLEN() calls to ml_get_buf_len(). Also do not
set ml_line_textlen in ml_replace_len() if "has_props" is set,
because "len_arg" also includes the size of text properties in
that case. (zeertzjq)
closes: vim/vim#1418394b7c3233e
Problem: Text properties position wrong after shifting text.
Solution: Adjust the text properties when shifting a block of text.
(closesvim/vim#10418)
4b93674159
Most of the patch is already merged. Add an assertion in place of "added".
Co-authored-by: LemonBoy <thatlemon@gmail.com>
Problem: Cursor column wrong with 'virtualedit' and conceal.
Solution: Correct cursor column at end of line if never reached.
(zeertzjq)
closes: vim/vim#14190253ff4dece
Problem: 'cursorline' and 'wincolor' highlight missing with concealed and
wrapped lines.
Solution: Apply 'cursorline' and 'wincolor' highlight to boguscols.
(zeertzjq)
Since 'cursorline' and 'wincolor' highlight apply after the end of the
line, it is more consistent to have them also apply to boguscols.
Assigning MAXCOL to values in ScreenCols[] make mouse click behave the
same with 'cursorline' and 'nocursorline', but such behavior may be
incorrect, as it puts the cursor on the next screen line. That may be
fixed in a future PR.
closes: vim/vim#1419221b0a3df8c
Problem: E1513 might be confusing
(Christoph Thoma)
Solution: reword error message, fix test to not
depend on the actual message
fixes: vim/vim#141890a32b8854b
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: winframe functions incorrectly recompute window positions if
the altframe wasn't adjacent to the closed frame, which is
possible if adjacent windows had 'winfix{width,height}' set.
Solution: recompute for windows within the parent of the altframe and
closed frame. Skip this (as before) if the altframe was
top/left, but only if adjacent to the closed frame, as
positions won't change in that case. Also correct the return
value documentation for win_screenpos. (Sean Dewar)
The issue revealed itself after removing the win_comp_pos call below
winframe_restore in win_splitmove. Similarly, wrong positions could result from
windows closed in other tabpages, as win_free_mem uses winframe_remove (at least
until it is entered later, where enter_tabpage calls win_comp_pos).
NOTE: As win_comp_pos handles only curtab, it's possible via other means for
positions in non-current tabpages to be wrong (e.g: after changing 'laststatus',
'showtabline', etc.). Given enter_tabpage recomputes it, maybe it's intentional
as an optimization? Should probably be documented in win_screenpos then, but I
won't address that here.
closes: vim/vim#14191
Nvim: don't reuse "wp" for "topleft" in winframe_remove, so the change
integrates better with the call to winframe_find_altwin before it.
5866bc3a0f
A lot of functions in move.c only worked for curwin, alternatively
took a `wp` arg but still only work if that happens to be curwin.
Refactor those that are needed for update_topline(wp) to work
for any window.
fixes#27723fixes#27720
Problem: small improvements can be made to split-move related
functions.
Solution: apply them (Sean Dewar):
Some of these changes were already applied to Nvim.
Here are the ones which were missing:
- Improve some doc comments (frame_flatten should still work for non-current
tabpages, despite the topframe check, which looks benign, though I'm unsure if
it's still needed; see vim/vim#2467).
- f_win_splitmove should check_split_disallowed on wp, not targetwin, as that's
what win_splitmove checks (though it's probably unnecessary to check
b_locked_split at all; see vim/vim#14109, which I hope to get around to
finishing at some point).
- Apply the winframe_restore comment changes, and remove win_comp_pos from after
winframe_restore in win_splitmove, as it shouldn't be necessary (no need to
remove it from nvim_win_set_config too, as it was already omitted).
Move win_append after winframe_restore in win_splitmove to match Vim.
closes: vim/vim#141855cac1a9bee
Problem: more places exist where curwin == prevwin, and it may even be
expected in some cases.
Solution: revert v9.1.0001, but document that it's possible instead.
(Sean Dewar)
I've had a change of heart for the following reasons:
- A quick 'n dirty [GitHub code search](https://github.com/search?q=%2F%28winnr%5C%28%5C%29%5Cs*%3D%3D%5Cs*winnr%5C%28%5B%27%22%5D%23%5B%27%22%5D%5C%29%7Cwinnr%5C%28%5B%27%22%5D%23%5B%27%22%5D%5C%29%5Cs*%3D%3D%5Cs*winnr%5C%28%5C%29%29%2F&type=code)
reveals some cases where it's expected in the wild.
Particularly, it made me aware `winnr() == winnr('#')` is possible when curwin
is changed temporarily during the evaluation of a &statusline expression item
(`%{...}`), and is used to show something different on the statusline
belonging to the previous window; that behaviour wasn't changed in v9.1.0001,
but it means curwin == prevwin makes sense in some cases.
- The definition and call sites of back_to_prevwin imply some expectation that
prevwin == wp (== curwin) is possible, as it's used to skip entering the
prevwin in that case.
- Prior to v9.1.0001, `:wincmd p` would not beep in the case that was patched in
v9.1.0001, but now does. That resulted in vim/vim#14047 being opened, as it affected
the CtrlP plugin.
I find it odd that `:wincmd p` had cases where it wouldn't beep despite doing
nothing, but it may be preferable to keep things that way (or instead also
beep if curwin == prevwin, if that's preferred).
- After more digging, I found cases in win_free_mem, enter_tabpage,
aucmd_restbuf and qf_open_new_cwindow where curwin == prevwin is possible
(many of them from autocommands). Others probably exist too, especially in
places where curwin is changed temporarily.
fixes: vim/vim#14047closes: vim/vim#14186d64801e913
Using -1 as the initial value can cause the pattern offset to become
negative, which in turn results in a negative subpriority, which fails
validation in nvim_buf_set_extmark.
Problem: current window number returned by tabpagewinnr may be outdated
when called from win_execute for the original tabpage.
Solution: update the original tabpage's tp_curwin in switch_win; use
{un}use_tabpage instead. Don't do it in restore_win to ensure
tp_curwin of the temporarily visited tabpage is unchanged from
switch_win visiting it, as before. (Sean Dewar)
Maybe restore_win should only restore tp_curwin if
`curtab == switchwin->sw_curtab`, in case the user changed tabpages from within
win_execute, but not doing that is consistent with the old behaviour.
related: vim/vim#14186e101028a5c
Current uses of vim_strup() calls memcpy()/strcpy() before calling vim_strup().
This results in 2 * strlen(string) operations.
We can trivially convert to lowercase while copying the string instead.
Tree-sitter queries can add URLs to a capture using the `#set!`
directive, e.g.
(inline_link
(link_text) @text.reference
(link_destination) @text.uri
(#set! @text.reference "url" @text.uri))
The pattern above is included by default in the `markdown_inline`
highlight query so that users with supporting terminals will see
hyperlinks. For now, this creates a hyperlink for *all* Markdown URLs of
the pattern [link text](link url), even if `link url` does not contain
a valid protocol (e.g. if `link url` is a path to a file). We may wish to
change this in the future to only linkify when the URL has a valid
protocol scheme, but for now we delegate handling this to the terminal
emulator.
In order to support directives which reference other nodes, the
highlighter must be updated to use `iter_matches` rather than
`iter_captures`. The former provides the `match` table which maps
capture IDs to nodes. However, this has its own challenges:
- `iter_matches` does not guarantee the order in which patterns are
iterated matches the order in the query file. So we must enforce
ordering manually using "subpriorities" (#27131). The pattern index of
each match dictates the extmark's subpriority.
- When injections are used, the highlighter contains multiple trees. The
pattern indices of each tree must be offset relative to the maximum
pattern index from all previous trees to ensure that extmarks appear
in the correct order.
- The `iter_captures` implementation currently has a bug where the
"match" table is only returned for the first capture within a pattern
(see #27274). This bug means that `#set!` directives in a query
apply only to the first capture within a pattern. Unfortunately, many
queries in the wild have come to depend on this behavior.
`iter_matches` does not share this flaw, so switching to
`iter_matches` exposed bugs in existing highlight queries. These
queries have been updated in this repo, but may still need to be
updated by users. The `#set!` directive applies to the _entire_ query
pattern when used without a capture argument. To make `#set!`
apply only to a single capture, the capture must be given as an
argument.
The original implementation has a worst-case of O(n^2). Every time
rem_backslash() is true, it calculates the length of the rest of the
string, and shift the rest of it to the left; backslash_halve_save()
copies the original string before doing backslash_halve().
The new implementation is O(n). It will find the first character where
rem_backslash() is true (it will do nothing if it's always false), and
shift the characters in-place; backslash_halve_save() avoids copying the
original string before doing backslash_halve().
Problem: too many STRLEN() calls
Solution: Make use of ml_get_len() calls instead
(John Marriott)
closes: vim/vim#14123bfcc895482
Co-authored-by: John Marriott <basilisk@internode.on.net>
runtime(vim): Update base-syntax, improve number matching (vim/vim#14175)
- Limit blob literals to an even number of hexadecimal digits and
correctly located dots.
- Match octal numbers.
The current version unsuccessfully attempts to match a leading '-' as
part of the float literal. It's actually parsed as part of the literal
for all numbers but the syntax file hasn't matched it like that for a
long time and highlights negative numbers as UNARY-MINUS NUMBER. This
will be fixed when better expression matching is implemented.
5cd86c6cff
Co-authored-by: dkearns <dougkearns@gmail.com>
Problem: Changing buffer in another window using win_execute() causes
it to show matchparen (after 9.0.0969).
Solution: Delay highlighting with SafeState in BufWinEnter.
(zeertzjq)
closes: vim/vim#1417749ffb6b428
