aboutsummaryrefslogtreecommitdiff
path: root/runtime/doc/vim_diff.txt
Commit message (Collapse)AuthorAge
...
* 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
* fix(runtime): source old color scheme in bundled color schemes (#26641)Evgeni Chasnovski2023-12-21
| | | | | | | | | | | Problem: Bundled color schemes use `:hi clear` and only define Vim's highlight groups. This results into Nvim-specific highlight groups using definitions from Nvim's default color scheme, which are not always linked to a Vim's highlight group. Solution: Restore links to Vim's highlight groups which were present before Nvim's default color scheme update.
* 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.
* feat(highlight): tweak default color schemeEvgeni Chasnovski2023-12-16
| | | | | | | | | | | | | | | | | | | | | | | | Problem: Updating default color scheme produced some feedback. Solution: Address the feedback. Outline of the changes: - Colors `Grey1` and `Grey2` are made a little bit more extreme (dark - darker, light - lighter) to increase overall contrast. - `gui` colors are treated as base with `cterm` colors falling back to using 0-15 colors which come from terminal emulator. - Update highlight group definition to not include attribute definition if it is intended to staty uncolored. - Tweak some specific highlight groups. - Add a list of Neovim specific highlight groups which are now defined differently in a breaking way. - Minor tweaks in several other places related to default color scheme.
* 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.
* feat(highlight): update default color schemeEvgeni Chasnovski2023-12-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Default color scheme is suboptimal. Solution: Start using new color scheme. Introduce new `vim` color scheme for opt-in backward compatibility. ------ Main design ideas - Be "Neovim branded". - Be minimal for 256 colors with a bit more shades for true colors. - Be accessible through high enough contrast ratios. - Be suitable for dark and light backgrounds via exchange of dark and light palettes. ------ Palettes - Have dark and light variants. Implemented through exporeted `NvimDark*` and `NvimLight*` hex colors. - Palettes have 4 shades of grey for UI elements and 6 colors (red, yellow, green, cyan, blue, magenta). - Actual values are computed procedurally in Oklch color space based on a handful of hyperparameters. - Each color has a 256 colors variant with perceptually closest color. ------ Highlight groups Use: - Grey shades for general UI according to their design. - Bold text for keywords (`Statement` highlight group). This is an important choice to increase accessibility for people with color deficiencies, as it doesn't rely on actual color. - Green for strings, `DiffAdd` (as background), `DiagnosticOk`, and some minor text UI elements. - Cyan as main syntax color, i.e. for function usage (`Function` highlight group), `DiffText`, `DiagnosticInfo`, and some minor text UI elements. - Red to generally mean high user attention, i.e. errors; in particular for `ErrorMsg`, `DiffDelete`, `DiagnosticError`. - Yellow very sparingly only with true colors to mean mild user attention, i.e. warnings. That is, `DiagnosticWarn` and `WarningMsg`. - Blue very sparingly only with true colors as `DiagnosticHint` and some additional important syntax group (like `Identifier`). - Magenta very carefully (if at all). ------ Notes - To make tests work without relatively larege updates, each one is prepended with an equivalent of the call `:colorscheme vim`. Plus some tests which spawn new Neovim instances also now use 'vim' color scheme. In some cases tests are updated to fit new default color scheme.
* 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.
* fix(defaults): set 'fsync' #26034Ploum2023-11-14
| | | | | | | | Problem: 'nofsync' may lose data if the system has a hard shutdown. #9888 Solution: Change default to 'fsync'. This may be revisited in the future when 'nofsync' can be made safer.
* 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>
* feat(tui): use TermResponse event for OSC responses (#25868)Gregory Anders2023-11-06
| | | | | | | | | | | | | When the terminal emulator sends an OSC sequence to Nvim (as a response to another OSC sequence that was first sent by Nvim), populate the OSC sequence in the v:termresponse variable and fire the TermResponse event. The escape sequence is also included in the "data" field of the autocommand callback when the autocommand is defined in Lua. This makes use of the already documented but unimplemented TermResponse event. This event exists in Vim but is only fired when Vim receives a primary device attributes response. Fixes: https://github.com/neovim/neovim/issues/25856
* refactor(options)!: unify `set_option` and `set_string_option`Famiu Haque2023-10-30
| | | | | | | | While the interfaces for setting number and boolean options are now unified by #25394, there is still a separate `set_string_option` function that is used for setting a string option. This PR removes that function and merges it with set_option. BREAKING CHANGE: `v:option_old` is now the old global value for all global-local options, instead of just string global-local options. Local value for a global-local number/boolean option is now unset when the option is set (e.g. using `:set` or `nvim_set_option_value`) without a scope, which means they now behave the same way as string options. Ref: #25672
* refactor(options)!: make OptionSet `v:` values use typvalFamiu Haque2023-10-17
| | | | BREAKING CHANGE: This breaks the OptionSet autocommand, as the `v:` values associated with it (`v:option_new`, `v:option_old`, `v:option_oldlocal` and `v:option_oldglobal`) are now the same type as the option, instead of all option values being converted to strings.
* fix(path): restore space separation in 'path' (#25571)zeertzjq2023-10-10
| | | Removing this behavior causes more inconsistencies and bugs.
* docs: fix misplaced mention of 'backupdir' (#25568)zeertzjq2023-10-10
|
* refactor: cleanupJustin M. Keyes2023-10-06
|
* fix: gf fails on "foo/bar.txt:1:2" on WindowsLeonardo Mello2023-10-06
| | | | | | | | | | | | | | | Problem: On Windows, "gf" fails on a filepath that has a line:column suffix. Example: E447: Can't find file "src/app/core/services/identity/identity.service.ts:64:23" Solution: - Remove ":" from 'isfname' on Windows. Colon is not a valid filename character (except for the drive-letter). - Handle drive letters specially in file_name_in_line(). Fixes #25160
* feat: ignore swapfile for running Nvim processes #25336Justin M. Keyes2023-10-04
| | | | | | | | | | | | | | | | | | | Problem: The swapfile "E325: ATTENTION" dialog is displayed when editing a file already open in another (running) Nvim. Usually this behavior is annoying and irrelevant: - "Recover" and the other options ("Open readonly", "Quit", "Abort") are almost never wanted. - swapfiles are less relevant for "multi-Nvim" since 'autoread' is enabled by default. - Even less relevant if user enables 'autowrite'. Solution: Define a default SwapExists handler which does the following: 1. If the swapfile is owned by a running Nvim process, automatically chooses "(E)dit anyway" (caveat: this creates a new, extra swapfile, which is mostly harmless and ignored except by `:recover` or `nvim -r`. 2. Shows a 1-line "ignoring swapfile..." message. 3. Users can disable the default SwapExists handler via `autocmd! nvim_swapfile`.
* feat(completion): support completing more string optionszeertzjq2023-10-01
|
* refactor(options)!: graduate some more shortmess flagsbfredl2023-09-25
| | | | | | | | A lot of updated places in the docs were already incorrect since long since they did not reflect the default behaviour. "[dos format]" could've been argued being better for discoverability but that ship has already sailed as it is no longer displayed by default.
* test(old): don't set options to default before every test (#25335)zeertzjq2023-09-24
| | | | | | | | Oldtests clean up after themselves, and the options that need operators to align with Vim all deny duplicates, so there is no need to set them to default. Also make the variable name that test_listchars.vim uses to align with Vim more obvious.
* fix(ui): always use stl/stlnc fillchars when drawing statusline (#25267)tj-moody2023-09-24
|
* refactor(options)!: graduate shortmess+=f flagbfredl2023-09-23
| | | | | | | Not everything needs to be crazy overconfigurable. Also fixes a warning in latest clang which didn't approve of the funky math switch statement in append_arg_number
* feat(highlight): add `FloatFooter` highlight groupEvgeni Chasnovski2023-08-26
| | | | | | Problem: No clear separation of floating title and footer highlighting. Solution: Add new `FloatFooter` highlight group.
* vim-patch:8.1.2046: SafeState may be triggered at the wrong momentzeertzjq2023-08-21
| | | | | | | | | | | | | Problem: SafeState may be triggered at the wrong moment. Solution: Move it up higher to after where messages are processed. Add a SafeStateAgain event to tigger there. https://github.com/vim/vim/commit/69198cb8c08f124729c41a4681f2d142228a9139 SafeStateAgain is N/A. Move SafeState functions to state.c. Co-authored-by: Bram Moolenaar <Bram@vim.org>
* vim-patch:9.0.1767: '.-' no allowed in highlight group names (#24814)zeertzjq2023-08-21
| | | | | | | | | | | | | | Problem: '.-' no allowed in highlight group names Solution: Allow dot and hyphen characters in highlight group names Allow dots and hyphens in group names. There does not seem to be any reason for these to be disallowed. closes: vim/vim#12807 https://github.com/vim/vim/commit/d4376dc3ebea91abcb4d9ef9963ef5b968048b78 Co-authored-by: Gregory Anders <greg@gpanders.com> Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com>
* feat(highlight): Allow hyphens (-) in highlight group names (#24714)Gregory Anders2023-08-15
| | | Fixes: https://github.com/neovim/neovim/issues/23184
* Merge #15440 close 'shell' :terminal automaticallyJustin M. Keyes2023-08-13
|\
| * Use Lua autocommand and make TermClose autocommand globalGregory Anders2023-08-10
| |
* | fix(events): avoid unnecessary CursorMoved (#24675)zeertzjq2023-08-12
|/ | | | | | Problem: Temporarily changing current window in a script causes CursorMoved to be triggerd. Solution: Don't trigger CursorMoved if neither curwin nor cursor changed between two checks.
* feat(defaults): treat "•" as a list item prefix #24623Justin M. Keyes2023-08-09
| | | | | | | | Problem: Nvim docs use "•" as a list item prefix but `gw{motion}` doesn't format such lists by default. Solution: Change the 'comments' option to include "fb:•" by default.
* docs: luaref cleanup #24541Justin M. Keyes2023-08-03
| | | | - drop "luaref-" prefix in favor of "lua-" or nothing, where possible. - remove redundant "luaref--lang…" and "luaref-api…" tags.
* docs: miscJustin M. Keyes2023-08-03
| | | | Co-authored-by: Kevin Pham <keevan.pham@gmail.com>
* docs: remove trailing spaces #24455ii142023-07-25
|
* docs(vim_diff): fixed inconsistent autocmds behavior #24453ii142023-07-24
|
* Merge pull request #24363 from lewis6991/docs/luatypesLewis Russell2023-07-17
|\ | | | | docs(lua): move some function docs to lua files
| * fix: doc errorsLewis Russell2023-07-17
| |
* | feat(options)!: remove compatible behaviours for vim 5.0 and earlierLewis Russell2023-07-17
|/
* vim-patch:9.0.1673: cannot produce a status 418 or 503 message (#24287)Gregory Anders2023-07-10
| | | | | | | | Problem: Cannot produce a status 418 or 503 message. Solution: Add err_teapot(). https://github.com/vim/vim/commit/80adaa8ae8398403ca4e9797219ea9a501fc76a5 Co-authored-by: Bram Moolenaar <Bram@vim.org>
* docs: MAINTAIN.md, nvim_get_markJustin M. Keyes2023-07-08
|
* refactor(defaults): use vim.region for visual star (*,#)Justin M. Keyes2023-07-06
| | | | | | | | | | | | | Problem: The parent commit added a new vim.get_visual_selection() function to improve visual star. But that is redundant with vim.region(). Any current limitations of vim.region() should be fixed instead of adding a new function. Solution: Delete vim.get_visual_selection(). Use vim.region() to get the visual selection. TODO: fails with visual "block" selections.
* fix(defaults): visual mode star (*,#) is fragileSteven Ward2023-07-06
| | | | | | | | | | | | Problem: Visual mode "*", "#" mappings don't work on text with "/", "\", "?", and newlines. Solution: Get the visual selection and escape it as a search pattern. Add functions vim.get_visual_selection and _search_for_visual_selection. Fix #21676
* docs: autocmds, miscJustin M. Keyes2023-06-25
|
* fix(messages): use "Vimscript" instead of "VimL" #24111Justin M. Keyes2023-06-22
| | | | followup to #24109 fix #16150
* test: spellcheck :help (vimdoc) files #24109Justin M. Keyes2023-06-22
| | | | | | | Enforce consistent terminology (defined in `gen_help_html.lua:spell_dict`) for common misspellings. This does not spellcheck English in general (perhaps a future TODO, though it may be noisy).
* docs: lsp, vim_diffJustin M. Keyes2023-06-22
| | | | | | | - quickstart - mark lsp.txt as `new_layout` - remove lsp-handler documentation for notifications: they don't have handlers because they don't have server responses.
* docs #22363Justin M. Keyes2023-06-19
| | | | | | | | | Co-authored by: zeertzjq <zeertzjq@outlook.com> Co-authored by: Steven Todd McIntyre II <114119064+stmii@users.noreply.github.com> Co-authored by: nobe4 <nobe4@users.noreply.github.com> - docs: mention --luadev-mod to run with lua runtime files When changing a lua file in the ./runtime folder, a new contributor might expect changes to be applied to the built Neovim binary.
* docs: various clarifications (#23999)zeertzjq2023-06-12
| | | | | Close #18907 Close #20314 Close #23749
* refactor(defaults): do not use C specific default values for options (#22500)Gregory Anders2023-06-06
| | | | | | | | | | The options 'path', 'include', and 'define' all use C-specific default values. This may have made sense a long time ago when Vim was mostly used just for writing C, but this is no longer the case, and we have ample support for filetype specific configuration. Make the default values of these options empty and move the C-specific values into a filetype plugin where they belong. Co-authored-by: zeertzjq <zeertzjq@outlook.com>