aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Merge pull request #27871 from bfredl/ui_flush_fixbfredl2024-03-16
|\ | | | | fix(ui): edge case around flushing in grid_line
| * fix(ui): fix edge case around flushingbfredl2024-03-15
| | | | | | | | | | ui_flush_buf() doesn't know about `lenpos` so `remote_ui_raw_line` needs to always handle it before flushing
* | fix(l10n): update Japanese translations (#27856)ite-usagi2024-03-16
| |
* | fix(man): pass modifiers also to :tag (#27878)zeertzjq2024-03-16
| | | | | | | | There aren't really many modifiers that take an effect on :tag (except maybe :confirm, :unsilent, :verbose), but pass them for consistency.
* | feat(man): allow opening pages in current window (#27861)Tomasz N2024-03-16
| | | | | | With :hide modifier, open page in current window.
* | Merge pull request #27873 from zeertzjq/vim-61887b3d6fd8zeertzjq2024-03-16
|\ \ | | | | | | vim-patch: Update Vim syntax
| * | vim-patch:b4b3d7de2413zeertzjq2024-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | runtime(vim): Update base-syntax, revert last change to vimUserFunc (vim/vim#14202) Fix highlighting of ":echo (expr)" (broken in commit 61887b3) by re-enabling the original fix for vim/vim#9987. Addresses https://github.com/vim/vim/pull/14199#issuecomment-1999732062. This will be fixed more generally when there is context-sensitive matching for commands and functions. https://github.com/vim/vim/commit/b4b3d7de2413bf277445ea724c9cbd5e6bf9a334 Co-authored-by: dkearns <dougkearns@gmail.com>
| * | vim-patch:61887b3d6fd8zeertzjq2024-03-15
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | runtime(vim): Update base-syntax, improve :echo and :execute highlighting (vim/vim#14199) Improve :echo and :execute highlighting. - Add better line-continuation support for both commands. - Improve the :execute command's expression argument matching. - Remove the fix for issue vim/vim#9987 as this is now handled by correctly matching the parens in :echo (...) as operator parens. https://github.com/vim/vim/commit/61887b3d6fd8b441c90416ea7855e1fe5a9ae32c Co-authored-by: dkearns <dougkearns@gmail.com>
* | Merge pull request #27867 from bfredl/intro_multigridbfredl2024-03-15
|\ \ | |/ |/| fix(ui): startup intro message should be visible with ext_multigrid
| * fix(ui): startup intro message should be visible with ext_multigridbfredl2024-03-15
| | | | | | | | | | | | | | | | 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.
* | Merge pull request #27858 from luukvbaal/nvim_set_cursorbfredl2024-03-15
|\ \ | | | | | | fix(ui): issues controlling cursor position with ext_cmdline
| * | fix(ui): ext_cmdline should not move cursor to curwinLuuk van Baal2024-03-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
| * | fix(api): update grid cursor in nvim_win_set_cursor()Luuk van Baal2024-03-15
| | | | | | | | | | | | | | | | | | 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.
* | | Merge pull request #27674 from glepnir/snippet_indentbfredl2024-03-15
|\ \ \ | |_|/ |/| | fix(snippet): correct indent with newline
| * | fix(snippet): correct indent with newlineglepnir2024-03-01
| | | | | | | | | | | | | | | | | | Problem: snippet newline use before line indent after expand. Solution: it should level + 1.
* | | refactor: remove unused "coloff" argument of win_put_linebuf() (#27866)zeertzjq2024-03-15
| | | | | | | | | | | | It isn't really used, and is always passed 0. Also rename "start_col" to "startcol" for consistency with "endcol".
* | | vim-patch:9.1.0181: no overflow check for string formatting (#27863)zeertzjq2024-03-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: no overflow check for string formatting Solution: Check message formatting function for overflow. (Chris van Willegen) closes: vim/vim#13799 https://github.com/vim/vim/commit/c35fc03dbd47582b256776fb11f11d8ceb24f8f0 Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
* | | vim-patch:9.1.0180: Cursor pos wrong when double-width chars are concealed ↵zeertzjq2024-03-15
| |/ |/| | | | | | | | | | | | | | | | | | | (#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 https://github.com/vim/vim/commit/010e1539d67442cc69a97bef6453efaf849d0db3
* | fix(highlight): don't show CursorColumn on current line (#27848)zeertzjq2024-03-15
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge pull request #27852 from bfredl/persistent_introbfredl2024-03-14
|\ \ | | | | | | fix(intro): make intro explicitly stateful
| * | fix(intro): make intro explicitly statefulbfredl2024-03-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | refactor(drawline): rename vcol_off to vcol_off_co (#27857)zeertzjq2024-03-14
| | | | | | | | | | | | | | | 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().
* | | Merge pull request #27854 from bfredl/boogalo_linesbfredl2024-03-14
|\ \ \ | | | | | | | | fix(api): fix set_lines viewport adjustment, but this time good
| * | | fix(api): fix set_lines viewport adjustment, but this time goodbfredl2024-03-14
| |/ / | | | | | | | | | fixes #27720
* / / fix(terminal): disable reflow againChristian Clason2024-03-14
|/ / | | | | | | | | | | | | reverts https://github.com/neovim/neovim/commit/c855eee919f2d4edc9b9fa91b277454290fbabfe This setting introduces constant CI failures on macos (see https://github.com/neovim/neovim/issues/23762).
* | Merge pull request #27851 from zeertzjq/vim-760f664213dezeertzjq2024-03-14
|\ \ | | | | | | vim-patch: reverts mswin.vim changes
| * | vim-patch:45da32964d6ezeertzjq2024-03-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 https://github.com/vim/vim/commit/45da32964d6e7e635af8fcf0b42e974b0b536ed3 Co-authored-by: Christian Brabandt <cb@256bit.org>
| * | vim-patch:760f664213dezeertzjq2024-03-14
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 https://github.com/vim/vim/commit/760f664213dea9a300454992ba1589f4601d622f Co-authored-by: Christian Brabandt <cb@256bit.org>
* | refactor(treesitter): move some logic into functionsLewis Russell2024-03-14
| |
* | fix(treesitter): highlight injections properlyLewis Russell2024-03-14
| | | | | | | | | | `on_line_impl` doesn't highlight single lines, so using pattern indexes to offset priority doesn't work.
* | Merge pull request #27850 from zeertzjq/vim-9.1.0172zeertzjq2024-03-14
|\ \ | | | | | | vim-patch:9.1.{0172,0177}: more code can use ml_get_buf_len()
| * | vim-patch:9.1.0177: Coverity reports dead codezeertzjq2024-03-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 https://github.com/vim/vim/commit/8c55d60658b7ee3458dca57fc5eec90ca9bb9bf3
| * | vim-patch:9.1.0172: More code can use ml_get_buf_len() instead of STRLEN()zeertzjq2024-03-14
|/ / | | | | | | | | | | | | | | | | | | | | | | 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 https://github.com/vim/vim/commit/94b7c3233ef534acc669b3083ed1fe59cf3a090b
* | vim-patch:8.2.4950: text properties position wrong after shifting text (#27849)zeertzjq2024-03-14
| | | | | | | | | | | | | | | | | | | | | | Problem: Text properties position wrong after shifting text. Solution: Adjust the text properties when shifting a block of text. (closes vim/vim#10418) https://github.com/vim/vim/commit/4b93674159d60c985de906c30f45dbaf2b64056f Most of the patch is already merged. Add an assertion in place of "added". Co-authored-by: LemonBoy <thatlemon@gmail.com>
* | Merge pull request #27847 from zeertzjq/vim-9.1.0174zeertzjq2024-03-14
|\ \ | | | | | | vim-patch:9.1.{0174,0176}: conceal fixes
| * | vim-patch:9.1.0176: Cursor column wrong with 'virtualedit' and concealzeertzjq2024-03-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Cursor column wrong with 'virtualedit' and conceal. Solution: Correct cursor column at end of line if never reached. (zeertzjq) closes: vim/vim#14190 https://github.com/vim/vim/commit/253ff4dece4e6cc4a9ff3ed935bc78f832b6fb7c
| * | vim-patch:9.1.0174: 'cursorline' and 'wincolor' hl missing with conceal and wrapzeertzjq2024-03-14
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 https://github.com/vim/vim/commit/21b0a3df8c4abb884489dfcc0c92b1bbe058f291
* | vim-patch:9.1.0178: E1513 might be confusing (#27846)zeertzjq2024-03-14
| | | | | | | | | | | | | | | | | | | | | | | | Problem: E1513 might be confusing (Christoph Thoma) Solution: reword error message, fix test to not depend on the actual message fixes: vim/vim#14189 https://github.com/vim/vim/commit/0a32b8854b52381fd17a6fcc5e38a3b9e77c8923 Co-authored-by: Christian Brabandt <cb@256bit.org>
* | vim-patch:9.1.0175: wrong window positions with 'winfix{width,height}' (#27845)Sean Dewar2024-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. https://github.com/vim/vim/commit/5866bc3a0f54115d5982fdc09bdbe4c45069265a
* | Merge pull request #27815 from bfredl/setlines_scrollbfredl2024-03-13
|\ \ | | | | | | fix(api/buffer): fix handling of viewport of non-current buffer
| * | fix(api/buffer): fix handling of viewport of non-current bufferbfredl2024-03-13
|/ / | | | | | | | | | | | | | | | | | | | | 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
* | fix(drawline): initialize linebuf_attr to 0 instead of -1 (#27840)zeertzjq2024-03-13
| | | | | | This also obviates the end-of-line loop when there is virtual text.
* | refactor: remove "once" argument of loop_uv_run() (#27841)zeertzjq2024-03-13
| | | | | | It is always set to true when used, and makes the code a bit confusing.
* | Merge pull request #27839 from seandewar/vim-9.1.0169Sean Dewar2024-03-12
|\ \ | | | | | | vim-patch:9.1.{0169,0170,0171,9a660d2883f9}
| * | vim-patch:9a660d2883f9Sean Dewar2024-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | runtime(doc): add reference to matchbufline() at :h search() related: vim/vim#14173 https://github.com/vim/vim/commit/9a660d2883f92b3a3761c964dc14363a8f70c8d8 Co-authored-by: Christian Brabandt <cb@256bit.org>
| * | vim-patch:9.1.0171: Small split-move related improvementsSean Dewar2024-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 https://github.com/vim/vim/commit/5cac1a9bee0798d70a7fd80363a1f697759638e8
| * | vim-patch:9.1.0170: Re-allow curwin == prevwin, but document it insteadSean Dewar2024-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 https://github.com/vim/vim/commit/d64801e913314d2e19dbb38f60e6d285238debff
| * | vim-patch:9.1.0169: current window number returned by tabpagewinnr may be ↵Sean Dewar2024-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 https://github.com/vim/vim/commit/e101028a5c896480c61fef7ea16855255925709b
* | | fix(treesitter): use 0 as initial value for computing maximum (#27837)Gregory Anders2024-03-12
|/ / | | | | | | | | 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.
* | refactor: avoid copying before vim_strup() if possible (#27830)James2024-03-13
| | | | | | | | | | | | 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.
generated by cgit (git 2.34.1) at 2025-06-24 05:00:09 +0000