aboutsummaryrefslogtreecommitdiff
path: root/runtime/lua/vim/_meta
Commit message (Collapse)AuthorAge
...
* fix(doc): improve doc generation of types using lpegLewis Russell2024-01-11
| | | | Added a lpeg grammar for LuaCATS and use it in lua2dox.lua
* feat(terminal): trigger TermRequest autocommand events (#22159)Ghjuvan Lacambre2024-01-09
| | | | | | | | | | This commit implements a new TermRequest autocommand event and has Neovim emit this event when children of terminal buffers emit an OSC or DCS sequence libvterm does not handle. The TermRequest autocommand event has additional data in the v:termrequest variable. Co-authored-by: Gregory Anders <greg@gpanders.com>
* fix(docs): make lines not overflow in vim docsJongwook Choi2024-01-09
| | | | | | | | | Problem: Some lines in the generated vim doc are overflowing, not correctly wrapped at 78 characters. This happens when docs body contains several consecutive 'inline' elements generated by doxygen. Solution: Take into account the current column offset of the last line, and prepend some padding before doc_wrap().
* vim-patch:9.1.0010: Keymap completion is not available (#26888)zeertzjq2024-01-05
| | | | | | | | | | | | | Problem: Keymap completion is not available Solution: Add keymap completion (Doug Kearns) Add keymap completion to the 'keymap' option, user commands and builtin completion functions. closes: vim/vim#13692 https://github.com/vim/vim/commit/81642d9d6ff5cd6a90a012b1b98632ce51eeb1a8 Co-authored-by: Doug Kearns <dougkearns@gmail.com>
* Merge pull request #26791 from wookayin/gendocLewis Russell2024-01-04
|\ | | | | refactor(gen_vimdoc): general refactoring on vimdoc generation
| * refactor(gen_vimdoc): generate function doc from metadata, not from xmlJongwook Choi2024-01-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: For function definitions to be included in the vimdoc (formatted) and to be exported as mpack data (unformatted), we had two internal representations of the same function/API metadata in duplicate; one is FunctionDoc (which was previously a dict), and the other is doxygen XML DOM from which vimdoc (functions sections) was generated. Solution: We should have a single path and unified data representation (i.e. FunctionDoc) that contains all the metadata and information about function APIs, from which both of mpack export and vimdoc are generated. I.e., vimdocs are no longer generated directly from doxygen XML nodes, but generated via: (XML DOM Nodes) ------------> FunctionDoc ------> mpack (unformatted) Recursive Internal | Formatting Metadata +---> vimdoc (formatted) This refactoring eliminates the hacky and ugly use of `fmt_vimhelp` in `fmt_node_as_vimhelp()` and all other helper functions! This way, `fmt_node_as_vimhelp()` can simplified as it no longer needs to handle generating of function docs, which needs to be done only in the topmost level of recursion.
* | refactor(column): define and use maximum 'statuscolumn' widthLuuk van Baal2024-01-04
| | | | | | | | | | Problem: The maximum 'statuscolumn' width and grow behavior is undocumented. Solution: Define, use and document the maximum 'statuscolumn' width and grow behavior.
* | fix(decorations): validate botline for on_winJaehwang Jung2024-01-04
|/ | | | | | | | | | | | | | | | | | | Problem: Many decoration providers (treesitter injection highlighting, semantic token highlighting, inlay hint) rely on the correctness of the `botline` argument of `on_win` callback. However, `botline` can be smaller than the actual line number of the last displayed line if some lines are folded. In such cases, some decorations will be missing in the lines not covered by `botline`. Solution: Validate `botline` when invoking `on_win`. NOTE: It seems that the old code was deliberately avoiding this presumably due to performance reasons. However, I haven't experienced noticeable lag after this change, and I believe the cost of botline computation would be much smaller than the cost of decoration providers.
* docs: clarify on_bytes argumentsJaehwang Jung2024-01-01
| | | | based on extmark_splice doc
* fix(builtin): parameter mismatch between winsaveview and winrestviewaltermo2023-12-31
|
* docs(eval): add parameter type for vim.fn.mode() (#26776)xvzc2023-12-28
|
* docs: small fixes (#26651)dundargoc2023-12-28
| | | | Co-authored-by: Gregory Anders <greg@gpanders.com> Co-authored-by: WillLillis <wlillis@umass.edu>
* feat(extmarks): add virt_text_repeat_linebreak flag (#26625)luukvbaal2023-12-26
| | | | | | Problem: Unable to predict which byte-offset to place virtual text to make it repeat visually in the wrapped part of a line. Solution: Add a flag to nvim_buf_set_extmark() that causes virtual text to repeat in wrapped lines.
* refactor(cpoptions): remove 'p'bfredl2023-12-25
| | | | | | Deleting a cpo flag a day keeps the doctor away We don't need two different ways to indent LISP code
* docs(options): add codeblock annotations to options.lua (#26696)Christian Clason2023-12-22
| | | | | Also consistently remove leading colons in examples Co-authored-by: zeertzjq <zeertzjq@outlook.com>
* vim-patch:9.0.2183: Maximum callback depth is not configurable (#26703)zeertzjq2023-12-22
| | | | | | | | | Problem: Maximum callback depth is not configurable. Solution: Revert patch 9.0.2103. Set 'maxfuncdepth' in test. fixes: vim/vim#13732 closes: vim/vim#13736 https://github.com/vim/vim/commit/fe583b1e5987fbfdb5f2141c133dbff9665ed301
* feat: generate types and docs for v variablesLewis Russell2023-12-21
|
* docs: small fixes (#26448)dundargoc2023-12-19
| | | | Co-authored-by: Gregory Anders <8965202+gpanders@users.noreply.github.com> Co-authored-by: Jordan Mandel <jordan.mandel@live.com>
* feat(api): add forward and back mouse buttonsAmanda Graven2023-12-18
|
* refactor: only reload colorscheme if &bg changed (#26598)Gregory Anders2023-12-16
| | | | | | | | | | Currently, setting &bg at all re-initializes highlights and reloads the active colorscheme, even if the actual value of &bg has not changed. With https://github.com/neovim/neovim/pull/26595 this causes a regression since &bg is set unconditionally based on the value detected from the terminal. Instead, only reload the colorscheme if the actual value of &bg has changed.
* vim-patch:82f19734bfcbChristian Clason2023-12-16
| | | | | | | | | | | runtime(doc): remove deprecation warning for gdefault Deprecated can be misunderstood as being slated for removal; slightly change wording to be clearer. https://github.com/vim/vim/commit/82f19734bfcbddbaee8d5d837f7b7a7119366020 Co-authored-by: dundargoc <gocdundar@gmail.com>
* feat(ui): completeopt support popup like vimmathew2023-12-16
|
* vim-patch:17dca3cb97cd (#26584)zeertzjq2023-12-15
| | | | | | | | | runtime(doc): grammar & typo fixes closes: vim/vim#13654 https://github.com/vim/vim/commit/17dca3cb97cdd7835e334b990565c8c0b93b1284 Co-authored-by: Dominique Pellé <dominique.pelle@tomtom.com>
* feat(lsp): more annotationsLewis Russell2023-12-14
|
* feat(nvim_open_term): convert LF => CRLF (#26384)Raphael2023-12-14
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Unlike termopen(), nvim_open_term() PTYs do not carriage-return the cursor on newline ("\n") input. nvim --clean :let chan_id = nvim_open_term(1, {}) :call chansend(chan_id, ["here", "are", "some", "lines"]) Actual behavior: here are some lines Expected behaviour: here are some lines Solution: Add `force_crlf` option, and enable it by default.
* Merge pull request #26407 from gpanders/default-tgcGregory Anders2023-12-06
|\ | | | | feat(defaults): enable 'termguicolors' by default when supported by terminal
| * feat(defaults): enable 'termguicolors' by default when supported by terminalGregory Anders2023-12-06
| | | | | | | | | | | | | | | | | | | | | | | | Enable 'termguicolors' automatically when Nvim can detect that truecolor is supported by the host terminal. If $COLORTERM is set to "truecolor" or "24bit", or the terminal's terminfo entry contains capabilities for Tc, RGB, or setrgbf and setrgbb, then we assume that the terminal supports truecolor. Otherwise, the terminal is queried (using both XTGETTCAP and SGR + DECRQSS). If the terminal's response to these queries (if any) indicates that it supports truecolor, then 'termguicolors' is enabled.
* | fix(json): allow objects with empty keys #25564Emanuel2023-12-06
|/ | | | | | | | | | | | | | | | | | | | Problem: Empty string is a valid JSON key, but json_decode() treats an object with empty key as ":help msgpack-special-dict". #20757 :echo json_decode('{"": "1"}') {'_TYPE': [], '_VAL': [['', '1']]} Note: vim returns `{'': '1'}`. Solution: Allow empty string as an object key. Note that we still (currently) disallow empty keys in object_to_vim() (since 7c01d5ff9286d262097484c680e3a4eab49e2911): https://github.com/neovim/neovim/blob/f64e4b43e1191ff30d902730f752875aa55682ce/src/nvim/api/private/converter.c#L333-L334 Fix #20757 Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
* refactor(api): complete conversion from `Dictionary` to `Dict(opts)` (#26365)Riccardo Mazzarini2023-12-05
|
* refactor: move some constants out of vim_defs.h (#26298)zeertzjq2023-11-29
|
* vim-patch:9.0.2135: No test for mode() when executing Ex commands (#26282)zeertzjq2023-11-29
| | | | | | | | | Problem: No test for mode() when executing Ex commands Solution: Add some test cases and simplify several other test cases. Also add a few more test cases for ModeChanged. closes: vim/vim#13588 https://github.com/vim/vim/commit/fcaeb3d42b228e73c669b2fce78f1d3fe112769f
* Merge pull request #26249 from bfredl/concealcharbfredl2023-11-28
|\ | | | | feat(decoration): allow conceal_char to be a composing char
| * feat(decoration): allow conceal_char to be a composing charbfredl2023-11-28
| | | | | | | | | | | | | | | | decor->text.str pointer must go. This removes it for conceal char, in preparation for a larger PR which will also handle the sign case. By actually allowing composing chars for a conceal chars, this becomes a feature and not just a refactor, as a bonus.
* | docs(lua): don't include remote-only API functions (#26266)zeertzjq2023-11-28
| |
* | vim-patch:9.0.2133: Cannot detect overstrike mode in Cmdline mode (#26263)zeertzjq2023-11-28
|/ | | | | | | | Problem: Cannot detect overstrike mode in Cmdline mode Solution: Make mode() return "cr" for overstrike closes: vim/vim#13569 https://github.com/vim/vim/commit/d1c3ef1f47c87d1da056c56564e1985fe6f2931d
* fix(lua): disallow vim.wait() in fast contextsLewis Russell2023-11-27
| | | | | | | `vim.wait()` cannot be called in a fast callback since the main loop cannot be run in that context as it is not reentrant Fixes #26122
* vim-patch:596a9f29c83a (#26146)zeertzjq2023-11-22
| | | | | | | | | | runtime(doc): Fix whitespace and formatting of some help files (vim/vim#13549) https://github.com/vim/vim/commit/596a9f29c83af85ace1a2702c88591851ad14df8 N/A patch: vim-patch:aabca259fa48 Co-authored-by: h_east <h.east.727@gmail.com>
* Merge pull request #25724 from luukvbaal/signmergebfredl2023-11-18
|\ | | | | refactor(sign): move legacy signs to extmarks
| * refactor(sign): move legacy signs to extmarksLuuk van Baal2023-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: The legacy signlist data structures and associated functions are redundant since the introduction of extmark signs. Solution: Store signs defined through the legacy commands in a hashmap, placed signs in the extmark tree. Replace signlist associated functions. Usage of the legacy sign commands should yield no change in behavior with the exception of: - "orphaned signs" are now always removed when the line it is placed on is deleted. This used to depend on the value of 'signcolumn'. - It is no longer possible to place multiple signs with the same identifier in a single group on multiple lines. This will now move the sign instead. Moreover, both signs placed through the legacy sign commands and through |nvim_buf_set_extmark()|: - Will show up in both |sign-place| and |nvim_buf_get_extmarks()|. - Are displayed by increasing sign identifier, left to right. Extmark signs used to be ordered decreasingly as opposed to legacy signs.
* | refactor(grid): make screen rendering more multibyte than ever beforebfredl2023-11-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: buffer text with composing chars are converted from UTF-8 to an array of up to seven UTF-32 values and then converted back to UTF-8 strings. Solution: Convert buffer text directly to UTF-8 based schar_T values. The limit of the text size is now in schar_T bytes, which is currently 31+1 but easily could be raised as it no longer multiplies the size of the entire screen grid when not used, the full size is only required for temporary scratch buffers. Also does some general cleanup to win_line text handling, which was unnecessarily complicated due to multibyte rendering being an "opt-in" feature long ago. Nowadays, a char is just a char, regardless if it consists of one ASCII byte or multiple bytes.
* | feat(tui): support DCS responses in TermResponse event (#26061)Gregory Anders2023-11-16
|/
* feat(tui): add 'termsync' option (#25871)Gregory Anders2023-11-14
| | | | | | | The 'termsync' option enables a mode (provided the underlying terminal supports it) where all screen updates during a redraw cycle are buffered and drawn together when the redraw is complete. This eliminates tearing or flickering in cases where Nvim redraws slower than the terminal redraws the screen.
* vim-patch:9.0.2103: recursive callback may cause issues on some archs (#26013)zeertzjq2023-11-13
| | | | | | | | | | | | | | | | | | | | | | | Problem: recursive callback may cause issues on some archs Solution: Decrease the limit drastically to 20 Recursive callback limit causes problems on some architectures Since commit 47510f3d6598a1218958c03ed11337a43b73f48d we have a test that causes a recursive popup callback function to be executed. However it seems the current limit of 'maxfuncdepth' option value is still too recursive for some 32bit architectures (e.g. 32bit ARM). So instead of allowing a default limit of 100 (default value for 'maxfuncdepth'), let's reduce this limit to 20. I don't think there is a use case where one would need such a high recursive callback limit and a limit of 20 seems reasonable (although it is currently hard-coded). closes: vim/vim#13495 closes: vim/vim#13502 https://github.com/vim/vim/commit/2076463e383901cef44685aaf4b63e4306444f9e Co-authored-by: Christian Brabandt <cb@256bit.org>
* vim-patch:1b08d2cd0789 (#25993)zeertzjq2023-11-12
| | | | | | | | | runtime(doc): clarify when formatoptions applies closes: vim/vim#13503 https://github.com/vim/vim/commit/1b08d2cd0789fd9aaae148a64ff46342730022d7 Co-authored-by: Christian Brabandt <cb@256bit.org>
* vim-patch:8.2.4932: not easy to filter the output of maplist()zeertzjq2023-11-09
| | | | | | | | | Problem: Not easy to filter the output of maplist(). Solution: Add mode_bits to the dictionary. (Ernie Rael, closes vim/vim#10356) https://github.com/vim/vim/commit/d8f5f766219273a8579947cc80b92580b6988a4b Co-authored-by: Ernie Rael <errael@raelity.com>
* vim-patch:8.2.4861: it is not easy to restore saved mappingszeertzjq2023-11-09
| | | | | | | | | Problem: It is not easy to restore saved mappings. Solution: Make mapset() accept a dict argument. (Ernie Rael, closes vim/vim#10295) https://github.com/vim/vim/commit/51d04d16f21e19d6eded98f9530d84089102f925 Co-authored-by: Ernie Rael <errael@raelity.com>
* vim-patch:8.2.4825: can only get a list of mappingszeertzjq2023-11-09
| | | | | | | | | | Problem: Can only get a list of mappings. Solution: Add the optional {abbr} argument. (Ernie Rael, closes vim/vim#10277) Rename to maplist(). Rename test file. https://github.com/vim/vim/commit/09661203ecefbee6a6f09438afcff1843e9dbfb4 Co-authored-by: Ernie Rael <errael@raelity.com>
* vim-patch:8.2.4820: not simple programmatic way to find a specific mappingzeertzjq2023-11-09
| | | | | | | | | Problem: Not simple programmatic way to find a specific mapping. Solution: Add getmappings(). (Ernie Rael, closes vim/vim#10273) https://github.com/vim/vim/commit/659c240cf769925ff432b88df8719e7ace4629b0 Co-authored-by: Ernie Rael <errael@raelity.com>
* vim-patch:8.2.4140: maparg() does not indicate the type of scriptzeertzjq2023-11-09
| | | | | | | | | Problem: maparg() does not indicate the type of script where it was defined. Solution: Add "scriptversion". https://github.com/vim/vim/commit/a9528b39a666dbaa026320f73bae4b1628a7fe51 Co-authored-by: Bram Moolenaar <Bram@vim.org>
* vim-patch:9.0.2095: statusline may look different than expected (#25941)zeertzjq2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: statusline may look different than expected Solution: do not check for highlighting of stl and stlnc characters statusline fillchar may be different than expected If the highlighting group for the statusline for the current window |hl-StatusLine| or the non-current window |hl-StatusLineNC| are cleared (or do not differ from each other), than Vim will use the hard-coded fallback values '^' (for the non-current windows) or '=' (for the current window). I believe this was done, to make sure the statusline will always be visible and be distinguishable from the rest of the window. However, this may be unexpected, if a user explicitly defined those fillchar characters just to notice that those values are then not used by Vim. So, let's assume users know what they are doing and just always return the configured stl and stlnc values. And if they want the statusline to be non-distinguishable from the rest of the window space, so be it. It is their responsibility and Vim shall not know better what to use. fixes: vim/vim#13366 closes: vim/vim#13488 https://github.com/vim/vim/commit/6a650bf696f1df3214b3d788947447c5bbf1a77d Co-authored-by: Christian Brabandt <cb@256bit.org>
generated by cgit (git 2.34.1) at 2025-06-24 11:26:56 +0000