aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
| * | | | | fix(completion): don't add backslashes to runtime pattern (#24296)zeertzjq2023-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Bashslashes added as regexp in runtime completion may be treated as path separator with some 'isfname' value. Solution: Make curly braces work for runtime completion and use it.
| * | | | | docs: gather @notes items into one sectionJustin M. Keyes2023-07-08
| | | | | | | | | | | | | | | | | | | | | | | | related: 21eacbfef399
| * | | | | docs: "Return (multiple)" headingJustin M. Keyes2023-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Lua functions that return multiple results are declared by using multiple `@return` docstring directives. But the generated docs don't make it obvious what this represents. Solution: - Generate a "Return (multiple)" heading for multiple-value functions. - Fix `@note` directives randomly placed after `@return`.
| * | | | | docs: MAINTAIN.md, nvim_get_markJustin M. Keyes2023-07-08
| | | | | |
| * | | | | fix(extmarks): fix wrong highlight after "combine" virt_text (#24281)Ibby2023-07-08
| | | | | |
| * | | | | fix(startup): run embedded Nvim with real path (#24282)zeertzjq2023-07-08
| | | | | | | | | | | | | | | | | | fix(startup): run embedded process with real path
| * | | | | fix(folds): fix missing virt_lines above when fold is hidden (#24274)zeertzjq2023-07-07
| | | | | |
| * | | | | fix(drawline): inline virt_text hl_mode inside syntax/extmark hl (#24273)zeertzjq2023-07-07
| | | | | |
| * | | | | fix(column): fix wrong cursor with 'statuscolumn' and cpo+=n (#24268)zeertzjq2023-07-06
| | | | | |
| * | | | | refactor(plines.c): update outdated comments (#24264)zeertzjq2023-07-06
| | | | | |
| * | | | | fix(ui): delay win_viewport until screen update #24182fredizzimo2023-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Sometimes, when nvim sends the `win_viewport` event, for example when scrolling with visible folds on the screen, it reports the `scroll_delta` value one batch into "future". So when the client application is trying to show the new viewport it's not yet updated, resulting in temporary corruption / screen flickering. For more details see #23609, and starting from [this comment]( https://github.com/neovide/neovide/pull/1790#issuecomment-1518697747) in https://github.com/neovide/neovide/pull/1790,, where the issue was first detected. Note that some of the conclusions in those are not fully accurate, but the general observations are. Solution: When there are pending updates to a Window, delay the `win_viewport` UI event until the updates are sent. This ensures that there's no flush between sending the viewport and updating of the lines corresponding to the new viewport. Document the existing viewport behaviour (for cases where there are no extra flushes), give a hint about how applications can deal with the slightly surprising behaviour of the viewport event being sent after the updates. Fixes https://github.com/neovim/neovim/issues/23609
| * | | | | Merge pull request #23228 from seandewar/cmdwin-jailzeertzjq2023-07-05
| |\ \ \ \ \ | | | | | | | | | | | | | | fix(api): use `text_locked()` to check for textlock
| | * | | | | fix(api): disallow some more functions during textlockSean Dewar2023-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: nvim_buf_set_text(), nvim_open_term() and termopen() all change buffer text, which is forbidden during textlock. Additionally, nvim_open_term() and termopen() may be used to convert the cmdwin buffer into a terminal buffer, which is weird. Solution: Allow nvim_buf_set_text() and nvim_open_term() in the cmdwin, but disallow nvim_open_term() from converting the cmdwin buffer into a terminal buffer. termopen() is not allowed in the cmdwin (as it always operates on curbuf), so just check text_locked(). Also happens to improve the error in #21055: nvim_buf_set_text() was callable during textlock, but happened to check textlock indirectly via u_save(); however, this caused the error to be overwritten by an unhelpful "Failed to save undo information" message when msg_list == NULL (e.g: an `<expr>` mapping invoked outside of do_cmdline()).
| | * | | | | fix(api): use text_locked() to check textlockSean Dewar2023-07-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: some API functions that check textlock (usually those that can change curwin or curbuf) can break the cmdwin. Solution: make FUNC_API_CHECK_TEXTLOCK call text_locked() instead, which already checks for textlock, cmdwin and `<expr>` status. Add FUNC_API_TEXTLOCK_ALLOW_CMDWIN to allow such functions to be usable in the cmdwin if they can work properly there; the opt-in nature of this attribute should hopefully help mitigate future bugs. Also fix a regression in #22634 that made functions checking textlock usable in `<expr>` mappings, and rename FUNC_API_CHECK_TEXTLOCK to FUNC_API_TEXTLOCK.
| * | | | | | fix(plines): don't return very large height on very long line (#24260)zeertzjq2023-07-05
| |/ / / / /
| * | | | | fix(edit): fix K_EVENT interfering with 'digraph' (#24258)zeertzjq2023-07-05
| | | | | |
| * | | | | fix(api): allow negative column arguments for nvim_buf_set_text (#23501)notomo2023-07-04
| | | | | |
| * | | | | feat(l10n): update Turkish translations #24246Emir SARI2023-07-04
| | | | | |
| * | | | | perf(ui-ext): approximate scroll_delta when scrolling too much (#24234)zeertzjq2023-07-04
| | | | | |
| * | | | | fix(ui-ext): "scroll_delta" handle topfill and skipcol (#24249)zeertzjq2023-07-04
| | | | | |
| * | | | | fix(api, lua): make blank lines in a message work properly (#24244)zeertzjq2023-07-04
| | | | | |
| * | | | | fix(plines): handle inline virtual text after last char (#24241)zeertzjq2023-07-03
| | | | | | | | | | | | | | | | | | Also remove dead code in win_lbr_chartabsize().
| * | | | | refactor: remove longdundargoc2023-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | long is 32-bits even on 64-bit windows which makes the type suboptimal for a codebase meant to be cross-platform.
| * | | | | Merge pull request #23891 from rickyz/grid_line_flagsbfredl2023-07-03
| |\ \ \ \ \ | | | | | | | | | | | | | | fix(ui): propagate line flags on grid_line events
| | * | | | | fix(ui): propagate line wrapping state on grid_line eventsRicky Zhou2023-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the TUI's line-wrapping behavior, which was broken with the migration to the msgpack-based UI protocol (see https://github.com/neovim/neovim/issues/7369#issuecomment-1571812273).
| * | | | | | vim-patch:9.0.1672: tabline highlight wrong after truncated double width ↵zeertzjq2023-07-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | label (#24223) Problem: Tabline highlight wrong after truncated double width label. Solution: Fill up half a double width character later. (closes vim/vim#12614) https://github.com/vim/vim/commit/d392a74c5a8af8271a33a20d37ae1a8ea422cb4b
| * | | | | | fix(startup)!: "nvim -l" message does not end with newline #24215zeertzjq2023-07-01
| | | | | | | | | | | | | | | | | | | | | Close #24180
| * | | | | | fix(api): nvim_parse_cmd error message in pcall() #23297Alexandre Teoi2023-07-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: nvim_parse_cmd() in pcall() may show an error message (side-effect): :lua pcall(vim.api.nvim_parse_cmd, vim.fn.getcmdline(), {}) E16: Invalid range Solution: Avoid emsg() in the nvim_parse_cmd() codepath. - refactor(api): add error message output parameter to get_address() - fix: null check emsg() parameter - refactor: remove emsg_off workaround from do_incsearch_highlighting() - refactor: remove emsg_off workaround from cmdpreview_may_show() - refactor: remove remaining calls to emsg() from parse_cmd_address() and get_address() - (refactor): lint set_cmd_dflall_range() - refactor: addr_error() - move output parameter to return value Fix #20339 TODO: These are the functions called by `get_address()`: ``` nvim_parse_cmd() -> parse_cmdline() -> parse_cmd_address() -> get_address() skipwhite() addr_error() qf_get_cur_idx() qf_get_cur_valid_idx() qf_get_size() qf_get_valid_size() mark_get() mark_check() assert() skip_regexp() magic_isset() > do_search() > searchit() ascii_isdigit() getdigits() getdigits_int32() compute_buffer_local_count() hasFolding() ``` From these functions, I found at least two that call emsg directly: - do_search() - seems to be simple to refactor - searchit() - will be more challenging because it may generate multiple error messages, which can't be handled by the current `errormsg` out-parameter. For example, it makes multiple calls to `vim_regexec_multi()` in a loop that possibly generate error messages, and later `searchit()` itself may generate another one: - https://github.com/neovim/neovim/blob/c194acbfc479d8e5839fa629363f93f6550d035c/src/nvim/search.c#L631-L647 - https://github.com/neovim/neovim/blob/c194acbfc479d8e5839fa629363f93f6550d035c/src/nvim/search.c#L939-L954 --------- Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
| * | | | | | feat(version): unverbose ":version", ":verbose version" #24195Justin M. Keyes2023-07-01
| | | | | | | | | | | | | | | | | | | | | | | | | |