Commit Graph

28979 Commits

Author SHA1 Message Date
bfredl
e0707d3529 fix(ui): fix edge case around flushing
ui_flush_buf() doesn't know about `lenpos` so `remote_ui_raw_line`
needs to always handle it before flushing
2024-03-15 12:07:04 +01:00
bfredl
f1c9228bba
Merge pull request #27858 from luukvbaal/nvim_set_cursor
fix(ui): issues controlling cursor position with ext_cmdline
2024-03-15 10:02:26 +01:00
bfredl
8350839a87
Merge pull request #27674 from glepnir/snippet_indent
fix(snippet): correct indent with newline
2024-03-15 09:32:03 +01:00
Luuk van Baal
d41b8d4758 fix(ui): ext_cmdline should not move cursor to curwin
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).
2024-03-15 09:15:56 +01:00
Luuk van Baal
c971f538ab fix(api): update grid cursor in nvim_win_set_cursor()
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.
2024-03-15 09:15:50 +01:00
zeertzjq
062c0245e3
refactor: remove unused "coloff" argument of win_put_linebuf() (#27866)
It isn't really used, and is always passed 0.
Also rename "start_col" to "startcol" for consistency with "endcol".
2024-03-15 14:45:58 +08:00
zeertzjq
d326e04860
vim-patch:9.1.0181: no overflow check for string formatting (#27863)
Problem:  no overflow check for string formatting
Solution: Check message formatting function for overflow.
          (Chris van Willegen)

closes: vim/vim#13799

c35fc03dbd

Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
2024-03-15 08:05:59 +08:00
zeertzjq
60491466f9
vim-patch:9.1.0180: Cursor pos wrong when double-width chars are concealed (#27862)
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#14197

010e1539d6
2024-03-15 06:56:45 +08:00
zeertzjq
ca7dd33fa7
fix(highlight): don't show CursorColumn on current line (#27848)
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.
2024-03-15 05:54:22 +08:00
bfredl
4de4f13eb3
Merge pull request #27852 from bfredl/persistent_intro
fix(intro): make intro explicitly stateful
2024-03-14 20:00:07 +01:00
bfredl
0570a19c8a fix(intro): make intro explicitly stateful
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.
2024-03-14 14:39:08 +01:00
zeertzjq
a6b6d036b1
refactor(drawline): rename vcol_off to vcol_off_co (#27857)
It is clearing that it's for conceal and matches the change from Vim
patch 9.0.1325.
Also correct some comments related to fix_for_boguscols().
2024-03-14 19:33:14 +08:00
bfredl
cdd0788c70
Merge pull request #27854 from bfredl/boogalo_lines
fix(api): fix set_lines viewport adjustment, but this time good
2024-03-14 12:24:33 +01:00
Christian Clason
120c4ec855 fix(terminal): disable reflow again
reverts c855eee919

This setting introduces constant CI failures on macos
(see https://github.com/neovim/neovim/issues/23762).
2024-03-14 19:22:16 +08:00
bfredl
fc2a56fe61 fix(api): fix set_lines viewport adjustment, but this time good
fixes #27720
2024-03-14 10:56:24 +01:00
zeertzjq
8955cef0c6
Merge pull request #27851 from zeertzjq/vim-760f664213de
vim-patch: reverts mswin.vim changes
2024-03-14 15:31:21 +08:00
zeertzjq
2aa84ce210 vim-patch:45da32964d6e
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.

fixes vim/vim#14195

45da32964d

Co-authored-by: Christian Brabandt <cb@256bit.org>
2024-03-14 15:04:31 +08:00
zeertzjq
ff972b88db vim-patch:760f664213de
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#13809

760f664213

Co-authored-by: Christian Brabandt <cb@256bit.org>
2024-03-14 15:03:47 +08:00
Lewis Russell
00c4962cd2 refactor(treesitter): move some logic into functions 2024-03-14 06:55:19 +00:00
Lewis Russell
12faaf40f4 fix(treesitter): highlight injections properly
`on_line_impl` doesn't highlight single lines, so using pattern indexes
to offset priority doesn't work.
2024-03-14 06:55:19 +00:00
zeertzjq
274e414c94
Merge pull request #27850 from zeertzjq/vim-9.1.0172
vim-patch:9.1.{0172,0177}: more code can use ml_get_buf_len()
2024-03-14 13:35:04 +08:00
zeertzjq
61b48e91b9 vim-patch:9.1.0177: Coverity reports dead code
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#14189

8c55d60658
2024-03-14 13:09:57 +08:00
zeertzjq
090d1fd0b8 vim-patch:9.1.0172: More code can use ml_get_buf_len() instead of STRLEN()
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#14183

94b7c3233e
2024-03-14 13:09:54 +08:00
zeertzjq
3502aa63f0
vim-patch:8.2.4950: text properties position wrong after shifting text (#27849)
Problem:    Text properties position wrong after shifting text.
Solution:   Adjust the text properties when shifting a block of text.
            (closes vim/vim#10418)

4b93674159

Most of the patch is already merged. Add an assertion in place of "added".

Co-authored-by: LemonBoy <thatlemon@gmail.com>
2024-03-14 12:40:17 +08:00
zeertzjq
b501a2354f
Merge pull request #27847 from zeertzjq/vim-9.1.0174
vim-patch:9.1.{0174,0176}: conceal fixes
2024-03-14 07:10:51 +08:00
zeertzjq
2af1dc0116 vim-patch:9.1.0176: Cursor column wrong with 'virtualedit' and conceal
Problem:  Cursor column wrong with 'virtualedit' and conceal.
Solution: Correct cursor column at end of line if never reached.
          (zeertzjq)

closes: vim/vim#14190

253ff4dece
2024-03-14 06:55:10 +08:00
zeertzjq
9599e5d28d vim-patch:9.1.0174: 'cursorline' and 'wincolor' hl missing with conceal and wrap
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#14192

21b0a3df8c
2024-03-14 06:55:08 +08:00
zeertzjq
b17be231a6
vim-patch:9.1.0178: E1513 might be confusing (#27846)
Problem:  E1513 might be confusing
          (Christoph Thoma)
Solution: reword error message, fix test to not
          depend on the actual message

fixes: vim/vim#14189

0a32b8854b

Co-authored-by: Christian Brabandt <cb@256bit.org>
2024-03-14 06:44:50 +08:00
Sean Dewar
bbb68e2a03
vim-patch:9.1.0175: wrong window positions with 'winfix{width,height}' (#27845)
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
2024-03-13 22:06:39 +00:00
bfredl
2a8cef6bd4
Merge pull request #27815 from bfredl/setlines_scroll
fix(api/buffer): fix handling of viewport of non-current buffer
2024-03-13 07:46:11 +01:00
bfredl
08fc1ebbaa fix(api/buffer): fix handling of viewport of non-current buffer
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 #27723
fixes #27720
2024-03-13 07:19:59 +01:00
zeertzjq
d5488633f6
fix(drawline): initialize linebuf_attr to 0 instead of -1 (#27840)
This also obviates the end-of-line loop when there is virtual text.
2024-03-13 11:36:41 +08:00
zeertzjq
93c93a0e36
refactor: remove "once" argument of loop_uv_run() (#27841)
It is always set to true when used, and makes the code a bit confusing.
2024-03-13 11:27:04 +08:00
Sean Dewar
9f59415243
Merge pull request #27839 from seandewar/vim-9.1.0169
vim-patch:9.1.{0169,0170,0171,9a660d2883f9}
2024-03-12 23:05:09 +00:00
Sean Dewar
c048beef6c
vim-patch:9a660d2883f9
runtime(doc): add reference to matchbufline() at :h search()

related: vim/vim#14173

9a660d2883

Co-authored-by: Christian Brabandt <cb@256bit.org>
2024-03-12 21:42:47 +00:00
Sean Dewar
6bbb02d9ba
vim-patch:9.1.0171: Small split-move related improvements
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#14185

5cac1a9bee
2024-03-12 21:38:39 +00:00
Sean Dewar
ca7b603d02
vim-patch:9.1.0170: Re-allow curwin == prevwin, but document it instead
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#14047
closes: vim/vim#14186

d64801e913
2024-03-12 21:14:40 +00:00
Gregory Anders
dc7ccd6bca
fix(treesitter): use 0 as initial value for computing maximum (#27837)
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.
2024-03-12 16:13:40 -05:00
Sean Dewar
29d0ed577c
vim-patch:9.1.0169: current window number returned by tabpagewinnr may be outdated
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#14186

e101028a5c
2024-03-12 21:05:54 +00:00
James
119390e7ce
refactor: avoid copying before vim_strup() if possible (#27830)
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.
2024-03-13 04:34:59 +08:00
James McCoy
dd0fc73bbe
Merge pull request #27808 from jamessan/gen_cflags-cleanup
Cleanup construction of command-lines for header generation
2024-03-12 14:00:29 -04:00
Gregory Anders
cb46f6e467
feat(treesitter): support URLs (#27132)
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.
2024-03-12 09:32:17 -05:00
Tomas Slusny
41fb98d6fa
fix: move fswatch linux check inside of vim.schedule (#27824)
Fixes issue reported in the original PR:
https://github.com/neovim/neovim/pull/27810

Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
2024-03-12 15:15:55 +08:00
James
3bd84317fb
refactor: avoid quadratic behavior in backslash_halve() (#27827)
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().
2024-03-12 14:35:53 +08:00
dundargoc
a74e869ffa
docs: small fixes (#27364)
Co-authored-by: C.D. MacEachern <craig.daniel.maceachern@gmail.com>
Co-authored-by: Ynda Jas <yndajas@gmail.com>
Co-authored-by: Owen Hines <TheOdd@users.noreply.github.com>
Co-authored-by: Wanten <41904684+WantenMN@users.noreply.github.com>
Co-authored-by: lukasvrenner <118417051+lukasvrenner@users.noreply.github.com>
Co-authored-by: cuinix <915115094@qq.com>
2024-03-12 13:51:53 +08:00
zeertzjq
ac8cd5368d
refactor: use ml_get_buf_len() in API code (#27825) 2024-03-12 10:44:53 +08:00
zeertzjq
b02a4d8ac3
vim-patch:9.1.0168: too many STRLEN() calls (#27823)
Problem:  too many STRLEN() calls
Solution: Make use of ml_get_len() calls instead
          (John Marriott)

closes: vim/vim#14123

bfcc895482

Co-authored-by: John Marriott <basilisk@internode.on.net>
2024-03-12 07:20:22 +08:00
zeertzjq
59e3bcfb00
vim-patch:5cd86c6cff94 (#27822)
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>
2024-03-12 07:20:04 +08:00
zeertzjq
e20e5ecf0a
vim-patch:9.1.0167: Changing buffer in another window causes it to show matchparen (#27820)
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#14177

49ffb6b428
2024-03-12 07:19:47 +08:00
zeertzjq
6481da3015
vim-patch:9.1.0166: Internal error with blockwise getregion() in another buffer (#27819)
Problem:  Internal error with blockwise getregion() in another buffer
Solution: Also change curwin->w_buffer when changing curbuf (zeertzjq)

closes: vim/vim#14179

5406eb8722
2024-03-12 07:19:30 +08:00